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ABSTRACT 


Traditionally,  the  design  and  implementation  of  a  conventional  database  sys¬ 
tem  begins  with  the  choice  of  a  data  model  followed  by  the  specification  of  a 
model-bzised  data  language.  Thus,  the  database  system  is  restricted  to  a  single 
data  model  and  a  specific  data  language.  An  alternative  to  this  traditional 
approach  to  database-system  development  is  the  multi-lingual  database  system 
(MLDS).  This  alternative  approach  enables  the  user  to  access  and  manage  a  large 
collection  of  databases  via  several  data  models  and  their  corresponding  data 
languages  without  the  aforementioned  restriction. 

In  this  thesis  we  present  the  implementation  of  a  entity-relationship/Daplex 

'  i. 

language  interface  for  the  MLDS.  Specifically,  w«  presenti^the  implementation  of 
an  interface  which  translates  Daplex  language  calls  into  attribute-based  data 
language  (ABDL)  requests. -Wc  describe  the  software  engineering  aspects  of  our 
implementation  and  an  overview  of  the  five  modules  which  comprise  our  entity- 
relationship/Daplex  language  interface. 
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I.  INTRODUCTION 


A.  MOTIVATION 

During  the  past  twenty  years  database  systems  have  been  designed  and 
implemented  using  what  we  refer  to  as  the  traditional  approach.  The  first  step  in 
the  traditional  approach  involves  choosing  a  data  model.  Candidate  data  models 
include  the  hierarchical  data  model,  the  relational  data  model,  the  network  data 
model,  the  entity-relationship  data  model,  or  the  attribute-based  data  model  to 
name  a  few.  The  second  step  specifies  a  model-based  data  language,  e.g.,  DL/I 
for  the  hierarchical  data  model,  or  Daplex  for  the  entity-relationship  data  model. 

A  number  of  database  systems  have  been  developed  using  this  methodology. 
For  example,  IBM  has  introduced  the  Information  Management  System  (IMS)  in 
the  sixties,  which  supports  the  hierarchical  data  model  and  the  hierarchical- 
model-based  data  language,  Data  Language  I  (DL/I).  Sperry  Univac  has  intro¬ 
duced  the  DMS-1100  in  the  early  seventies,  which  supports  the  network  data 
model  and  the  network-model-based  data  language,  CODASYL  Data  Manipula¬ 
tion  Language  (CODASYL-DML).  More  recently,  there  has  been  IBM’s  intro¬ 
duction  of  the  SQL/ Data  System  which  supports  the  relational  model  and  the 
relational- model- based  data  language.  Structured  English  Query  Language  (SQL). 
The  result  of  this  traditional  approach  to  database  system  development  is  a 
homogeneous  databeise  system  that  restricts  the  user  to  a  single  data  model  and  a 
specific  model-based  data  language. 

An  unconventional  approach  to  database  system  development,  referred  to  as 
the  Multi-lingual  Database  System  (MLDS)  [Ref.  l],  alleviates  the  aforementioned 
restriction.  This  new  system  affords  the  user  the  ability  to  access  and  manage  a 
large  collection  of  databases  via  several  data  models  and  their  corresponding  data 
languages.  The  design  goals  of  the  MLDS  involve  developing  a  system  that  is 
accessible  via  four  different  interfaces,  the  hierarchical/DL/I,  relational/SQL, 
network/DML,  and  entity-relationship/Daplex  interfaces. 


There  are  several  advantages  in  developing  such  a  system.  Perhaps  the  most 
practical  of  these  involves  the  reusability  of  database  transactions  developed  on 
an  existing  database  system.  In  MLDS,  there  is  no  need  for  the  user  to  convert 
a  transaction  from  one  data  language  to  another.  MLDS  permits  the  running  of 
database  transactions  written  in  different  data  languages.  Therefore,  the  user 
does  not  have  to  perform  either  manual  or  automated  translation  of  existing  tran¬ 
sactions  in  order  to  execute  a  transaction  in  MLDS.  MLDS  provides  the  same 
results  even  if  the  data  language  of  the  transaction  originates  at  a  different 
database  system. 

A  second  advantage  deals  with  the  economy  and  effectiveness  of  hardware 
upgrade.  Frequently,  the  hardware  supporting  the  database  system  is  upgraded 
because  of  technological  advancements  or  system  demand.  With  the  traditional 
approach,  this  type  of  hardware  upgrade  has  to  be  provided  for  all  of  the  dif¬ 
ferent  database  systems  in  use,  so  that  all  of  the  users  may  experience  system 
performance  improvements.  This  is  not  the  case  in  MLDS,  where  only  the 
upgrade  of  a  single  system  is  necessary.  In  MLDS,  the  benefits  of  a  hardware 
upgrade  are  uniformly  distributed  across  all  users,  despite  their  use  of  different 
models  and  data  languages. 

Thirdly,  a  multi-lingual  database  system  allows  users  to  explore  the  desirable 
features  of  the  different  data  models  and  then  use  these  features  to  better  support 
their  applications.  This  is  possible  because  MLDS  supports  a  variety  of 
databases  structured  in  any  of  the  well-known  data  models. 

It  is  apparent  that  there  exists  ample  motivation  to  develop  a  multi-lingual 
database  system  with  many  data  model/data  language  interfaces.  In  this  thesis, 
an  entity-relationship/Daplex  MLDS  interface  is  developed. 

B.  THE  MULTI-LINGUAL  DATABASE  SYSTEM 

A  detailed  discussion  of  each  of  the  components  of  MLDS  is  provided  in  sub¬ 
sequent  chapters.  In  this  section  we  provide  an  overview  of  the  organization  of 
MLDS.  This  assists  the  reader  in  understanding  how  the  different  components  of 
MLDS  are  related. 

Figtire  1  shows  the  system  structure  of  a  multi-lingual  database  system.  The 
user  interacts  with  the  system  through  the  language  interface  layer  (LIL),  using  a 


chosen  user  data  model  (UDM)  to  issue  transactions  written  in  a  corresponding 
model-based  user  data  language  (UDL).  LIL  routes  the  user  transactions  to  the 
kernel  mapping  system  (KMS).  KMS  performs  one  of  two  possible  t2isks.  First, 
KMS  transforms  a  UDM-based  database  definition  to  a  database  definition  of  the 
kernel  data  model  (KDM),  when  the  user  specifies  that  a  new  databaise  is  to  be 
created.  When  the  user  specifies  that  UDL  transaction  is  to  be  executed,  KMS 
translates  UDL  transaction  to  a  transaction  in  the  kernel  data  language  (KDL). 
In  the  first  task,  KMS  forwards  KDM  data  definition  to  the  kernel  controller 
(KC).  KC,  in  turn,  sends  KDM  database  definition  to  the  kernel  database  system 
(KDS).  When  KDS  is  finished  with  processing  KDM  database  definition,  it 
informs  KC.  KC  then  notifies  the  user,  via  LIL,  that  the  database  definition  has 
been  processed  and  that  loading  of  the  database  records  may  begin.  In  the 


■ 


UDM 

;  User  Data  Model 

UDL 

:  User  Data  Language 

LIL 

:  Language  Interface  Layer 

KMS 

:  Kernel  Mapping  System 

KC 

;  Kernel  Controller 

KFS 

:  Kernel  Formatting  System 

KDM 

:  Kernel  Data  Model 

KDL 

:  Kernel  Data  Language 

KDS 

:  Kernel  Database  System 

Figure  1.  The  Multi-Lingual  Database  System. 

second  task,  KMS  sends  KDL  transactions  to  KC.  When  KC  receives  KDL  tran¬ 
sactions,  it  forwards  them  to  KDS  for  execution.  Upon  completion,  KDS  sends 
the  results  in  the  KDM  form  back  to  KC.  KC  routes  the  results  to  the  kernel 
formatting  system  (KFS).  KFS  reformats  the  results  from  the  KDM  form  to  the 
UDM  form.  KFS  then  displays  the  results  in  the  correct  UDM  form  via  LIL. 

The  four  modules,  LIL,  KMS,  KC,  and  KFS,  are  collectively  known  as  the 
language  interface.  Four  similar  modules  are  required  for  each  other  language 
interface  of  the  MLDS.  For  example,  there  are  four  sets  of  these  modules  where 
one  set  is  for  the  hierarchical/DL/I  language  interface,  one  for  the  relational/SQL 
language  interface,  one  for  the  network/DML  language  interface,  and  one  for  the 
entity-relationship/Daplex  language  interface.  However,  if  the  user  writes  the 
transaction  in  the  native  mode  (i.e.,  in  KDL),  there  is  no  need  for  an  interface. 

In  our  implementation  of  the  entity-relationship/Daplex  language  interface, 
we  develop  the  code  for  the  four  modules.  However,  we  do  not  integrate  these 
modules  with  the  KDS  as  shown  in  Figure  1.  The  Laboratory  of  Database  Sys¬ 
tems  Research  at  the  Naval  Postgraduate  School  has  procurred  the  new  computer 
equipment  for  the  KDS.  When  the  equipment  is  installed,  the  KDS  is  to  be 
ported  over  to  the  new  equipment.  The  MLDS  software  is  then  to  be  integrated 
with  the  KDS.  Although  not  a  very  difficult  undertaking,  it  is  neverless  outside 
the  focus  of  this  thesis. 

C.  THE  KERNEL  DATA  MODEL  AND  LANGUAGE 

The  choice  of  a  kernel  data  model  and  a  kernel  data  language  is  the  key  deci¬ 
sion  in  the  development  of  a  multi-lingual  database  system.  The  overriding  ques¬ 
tion,  when  making  such  a  choice,  is  whether  the  kernel  data  model  and  kernel 
data  language  is  capable  of  supporting  the  required  data-model  transformations 
and  data-language  translations  for  the  language  interfaces. 

The  attribute-based  data  model  proposed  by  Hsiao  [Ref.  2],  extended  by 
Wong  [Ref.  3],  and  studied  by  Rothnie  [Ref.  4],  along  with  the  attribute-based 
data  language  (ABDL),  defined  by  Banerjee  [Ref.  5],  have  been  shown  to  be 
acceptable  candidates  for  the  kernel  data  model  and  kernel  data 
language,  respectively. 


Why  is  the  determination  of  a  kernel  data  model  and  kernel  data  language  so 
important  for  MLDS?  No  matter  how  multi-lingual  MLDS  may  be,  if  the  under¬ 
lying  database  system  (i.e.,  KDS)  is  slow  and  inefficient,  then  the  interfaces  may 
be  rendered  useless  and  untimely.  Hence,  it  is  important  that  the  kernel  data 
model  and  kernel  language  be  supported  by  a  high-performance  and  great- 
capacity  database  system.  Currently,  only  the  attribute-baised  data  model  and 
the  attribute-based  data  language  are  supported  by  such  a  system.  This  system 
is  the  multi-backend  database  system  (MBDS)  [Ref.  1]. 

D.  THE  MULTI-BACKEND  DATABASE  SYSTEM 

The  multi-backend  database  system  (MBDS)  has  been  designed  to  overcome 
the  performance  problems  and  upgrade  issues  related  to  the  traditional  approach 
of  database  system  design.  This  goal  is  realized  through  the  utilization  of 
multiple-backends  connected  in  a  parallel  fashion.  These  backends  have  identical 
hardware,  replicated  software,  and  their  own  disk  systems.  In  a  multiple-backend 
configuration,  there  is  a  backend  controller,  which  is  responsible  for  supervising 
the  execution  of  database  transactions  and  for  interfacing  with  the  hosts  and 
users.  The  backends  perform  the  database  operations  with  the  database  stored 
on  the  disk  system  of  the  backends.  The  controller  and  backends  are  connected 
by  a  communication  bus.  Users  access  the  system  through  either  the  hosts  or  the 
controller  directly  (see  Figure  2). 

Performance  gains  are  realized  by  increasing  the  number  of  backends.  If  the 
size  of  the  database  and  the  size  of  the  responses  to  the  transactions  remain  con¬ 
stant,  then  MBDS  produces  a  reciprocal  decreeise  in  the  response  times  for  the 
user  transactions  when  the  number  of  backends  is  increased.  On  the  other  hand, 
if  the  number  of  backends  is  increased  proportionally  with  the  increase  in  data¬ 
bases  and  responses,  then  MBDS  produces  invariant  response  times  for  the  same 
transactions.  A  more  detailed  discussion  of  MBDS  is  found  in  [Ref.  6]. 

E.  THESIS  OVERVIEW 

The  organization  of  our  thesis  is  as  follows:  In  Chapter  II,  we  discuss  the 
software  engineering  sispects  of  our  implementation.  This  includes  a  discussion  of 
our  design  approach,  as  well  as  a  review  of  the  global  data  structures  used  for  the 
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Backend  Store  1 


Bus 


Figure  2.  The  Multi-Backend  Database  System, 
implementation.  Chapter  III  discusses  the  storage  and  creation  of  the  Daplex 
schemas.  In  Chapter  IV,  we  outline  the  functionality  of  the  language  interface 
layer.  In  Chapter  V,  we  articulate  the  processes  constituting  the  kernel  mapping 
system.  In  Chapter  VI,  we  conclude  the  thesis. 

Appendbc  A  contains  the  data  structure  used  for  the  interface,  and  Appendix 
B  provides  the  modules  for  the  storage  and  retrieval  of  the  Daplex  schemas.  The 
detailed  specifications  of  the  interface  modules  (i.e.,  LIL  and  KMS)  are  given  in 
Appendices  C  and  D  respectively.  The  specifications  of  the  source  data  language, 
Daplex,  and  the  target  data  language,  ABDL,  are  found  in  [Ref.  7]  and  [Ref.  8[, 
respectively.  Throughout  this  thesis,  we  provide  examples  of  Daplex  requests 
and  their  translated  ABDL  equivalents.  All  examples  involving  database 


operations  presented  in  this  thesis  are  based  on  the  university  database  described 
in  the  Daplex  User’s  Manual  [Ref.  7],  and  shown  in  Figure  3. 


DATABASE  university  IS 

TYPE  person; 

SUBTYPE  employee; 

SUBTY'PE  support_staff; 

SUBTYPE  faculty; 

SUBTYPE  student; 

SUBTYPE  graduate; 

SUBTYPE  undergraduate; 

TYPE  course; 

TYPE  department; 

TYPE  enrollment; 

TYPE  rank_name  IS  (assistant, associate, full); 
TYPE  semester_name  IS  (fall,  spring,  summer); 
TYPE  grade_point  IS  FLOAT  RA.N'GE  0.0  ..  4.0; 

TYPE  person  IS 
ENTITY 

name  :  STRI.NG  (1  ..  25); 

ssn  ;  STRING  (1  ..  9)  :=  ”000000000"; 

END  ENTITY; 

SUBTYPE  employee  IS  person 
ENTITY 

home _address  :  STRING  (I  ..  50); 
office  :  STRING  (1  ..  8); 
phones  :  SET  OF  STRING  (1  ..  7); 
salary  :  FLOAT; 

dependents  ;  INTEGER  RANGE  0  ..  10  ; 
END  ENTITY; 

SUBTYPE  support^staff  IS  employee 
ENTITY 

supervisor  :  employee  WITHNULL; 
fulljime  :  BOOLEAN; 

END  ENTITY; 

SUBTYPE  faculty  IS  employee 
ENTITY 

rank  ;  rank^name; 

teaching  :  SET  OF  course; 
tenure  :  BOOLEAN  .=  FALSE; 

dept  :  department; 

END  ENTITY; 


SUBTYPE  student  IS  person 
ENTITY 

advisor  :  faculty  WITHNULL; 

major  :  department; 

enrollments  :  SET  OF  enrollment; 

END  ENTITY; 

SUBTYPE  graduate  IS  student 
ENTITY 

advisory _committee  ;  SET  OF  faculty; 

END  ENTITY; 

SUBTYPE  undergraduate  IS  student 
ENTITY 

gpa  :  grade_point  :=  0.0; 

year  :  INTEGER JIANGE  1  ..  4  :=  1; 

END  ENTITY; 

TYPE  course  IS 
ENTITY 

title  ;  STRING  (1  ..  10); 
dept  :  department; 

semester  :  semester _name; 

credits  ;  INTEGER; 

END  ENTITY; 

TYPE  department  IS 
ENTITY 

name  ;  STRING  (1  ..  20); 

head  :  faculty  WITHNULL; 

END  ENTITY; 

TYPE  enrollment  IS 
ENTITY 

class  :  course; 

grade  :  grade_point: 

END  ENTITY; 

UNIQUE  ssn  WITHIN  person; 

UNIQUE  name  WITHIN  department; 
UNIQUE  title,  semester  WITHIN  course; 
OVERLAP  graduate  WITH  faculty; 


ND  university; 


Figure  5.  The  University  Database. 


II.  SOFTWARE  ENGINEERING  OF  A  LANGUAGE  INTERFACE 


In  this  chapter,  we  discuss  the  various  software  engineering  aspects  of 
developing  a  language  interface.  First,  we  describe  our  design  goals,  and  then 
outline  the  design  approach  that  we  have  taken  to  implement  the  interface. 
Included  in  this  section  are  discussions  of  our  implementation  strategy,  our 
software  development  techniques,  and  the  salient  characteristics  of  the  language 
interface  software.  Next,  a  critique  of  our  implementation  is  provided,  and  then 
we  describe  the  data  structures  used  in  the  interface.  Finally,  we  provide  an 
organizational  description  of  the  next  four  chapters. 

A.  DESIGN  GOALS 

We  are  motivated  to  implement  a  Daplex  interface  for  MLDS  using  MBDS 
as  the  kernel  database  system,  the  attribute-based  data  model  as  the  kernel  data 
model,  and  the  attribute-based  data  language,  ABDL,  as  the  kernal  data 
language.  It  is  important  to  note  that  we  do  not  propose  changes  to  the  kernel 
database  system  or  language.  Instead,  our  implementation  resides  entirely  in  the 
host  computer.  All  user  transactions  in  Daplex  are  processed  in  the  Daplex  inter¬ 
face.  MBDS  continues  to  receive  and  process  requests  in  the  syntax  and  seman¬ 
tics  of  ABDL. 

In  addition,  our  interface  will  be  transparent  to  the  user.  For  example,  an 
employee  in  a  corporate  environment  with  previous  Daplex  experience  could  log 
into  our  system,  issue  a  Daplex  request  and  receive  resultant  data  in  an  entity- 
relationship  format.  The  employee  requires  no  training  in  ABDL  or  MBDS 
procedures  prior  to  utilizing  the  system. 

B.  AN  APPROACH  TO  THE  DESIGN 

1.  The  Implementation  Strategy 

There  are  a  number  of  different  strategies  we  might  have  employed  in  the 
implementation  of  the  Daplex  language  interface.  For  example,  there  is  the 
build-it-twice  full-prototype  approach,  the  level-by-level  top-down  approach,  the 


incremental  development  approach,  and  the  advancemanship  approach 
[Ref.  9;  pp.  41-46].  We  have  predicated  our  choice  on  minimizing  the 
"software-crisis”  eis  described  by  Boehm  [Ref.  9:  pp.  14-31). 

The  strategy  we  have  decided  upon  is  the  level-by-level  top-down 
approach.  Our  choice  is  b<ised  on  first,  a  time  constraint.  The  interface  heis  to 
be  developed  in  approximately  two  quarters.  Second,  the  level-by-level  top-down 
approach  lends  itself  to  the  natural  evolution  of  the  interface.  The  system  is  ini¬ 
tially  thought  of  aus  a  "black  box"  (see  Figtire  1  again)  that  accepts  Daplex  tran¬ 
sactions  and  then  returns  the  appropriate  results.  The  "black  box"  is  then 
decomposed  into  its  four  modules,  LIL,  KMS,  KC.  and  KFS.  These  modules,  in 
turn,  are  further  decomposed  into  the  necessary  functions  and  procedures  to 
accomplish  the  appropriate  tasks. 

2.  Techniques  for  Software  Development 

In  order  to  achieve  our  design  goals,  it  is  important  to  employ  effective 
software  engineering  techniques  during  all  phases  of  the  software  development 
life-cycle.  These  phases,  as  defined  by  Ledthrum  [Ref.  10:  p.  27],  are  as  follows: 

(1)  Requirements  Specification  -  This  phase  involves 
stating  the  purpose  of  the  software:  "what"  is  to 
be  done,  not  "how"  it  is  to  be  done. 

(2)  Design  -  During  this  phase  an  algorithm  is  devised 
to  carry  out  the  specification  produced  in  the 
previous  phase.  That  is,  "how"  to  implement  the 
system  is  specified  during  this  phase. 

(3)  Coding  -  In  this  phase,  the  design  is  translated 
into  a  programming  language. 

(4)  Validation  -  During  this  phase,  it  is  ensured  that 
the  developed  system  functions  as  originally 
intended.  That  is,  it  is  verified  that  the  system 
actually  does  what  it  is  supposed  to  do. 

The  first  phase  of  the  life-cycle  hats  already  been  performed.  The 
research  done  by  Demurjian  and  Hsiao  [Ref.  l]  has  described  the  motivation, 
goals,  and  structure  of  MLDS.  The  research  conducted  by  Goisman  [Ref.  11] 
has  extended  this  work  to  describe  in  detail  the  purpose  and  design  of  the  Daplex 
interface.  Accordingly,  the  requirements  specifications  are  derived  from  the 
above  research. 


The  system  implementation  methodology  was  essentially  accomplished 
and  proven  during  the  implementation  of  DL/I  and  SQL  into  MLDS 
[Refs.  12  and  13].  Our  task  was  to  adapt  the  DL/I  and  SQL  approaches  as 
necessary  for  the  Daplex  implementation. 

We  have  used  the  C  programming  language  [Ref.  14]  to  translate  the 
design  into  executable  code.  Initially,  we  were  not  conversant  in  the  language. 
However,  the  simple  syntax  of  C  and  our  background  in  structured  languages  has 
made  C  relatively  easy  for  us  to  learn. 

The  main  advantage  of  C  is  the  programming  environment  in  which  it 
resides,  the  UNIX  operating  system.  This  environment  has  permitted  us  to  parti¬ 
tion  the  Daplex  interface,  and  then  manage  these  parts  in  an  effective  and  effi¬ 
cient  manner.  The  primary  disadvantage  to  the  use  of  C  is  that  the  poor  error 
diagnostics  presented  by  the  C  compiler  can  and  at  times  did  make  debugging 
difficult.  There  is  an  on-line  debugger  available  in  UNIX  for  use  with  C,  but  we 
chose  to  use  conditional  computation  and  diagnostic  print  statements  to  aid  in 
the  debugging  process.  To  validate  our  system  we  have  used  path  testing  [Ref 
15],  a  traditional  testing  technique.  We  have  checked  boundary  cases,  and  we 
have  tt-  “d  those  cases  considered  "normal".  It  is  noteworthy  to  mention  that 
testing  does  not  prove  the  system  correct,  but  may  only  indicate  the  absence  of 
problems  with  the  cases  that  have  been  tested. 

3.  Characteristics  of  the  Interface  Software 

We  realize  that  in  order  for  the  Daplex  interface  to  be  successful,  that  it 
must  be  well  designed  and  well  structured.  Further,  we  are  cognizant  of  certain 
characteristics  that  the  interface  must  possess.  Specifically,  it  must  be  simple, 
and  easily  read  and  understood. 

The  ease  with  which  the  code  can  be  understood  is  vital  to  keeping  the 
program  maintenance  effort  low.  As  reported  by  Fairley  [Ref.  16:  p.  82],  roughly 
60%  of  all  software  life-cycle  costs  are  incurred  after  the  software  becomes  opera¬ 
tional,  so  it  is  important  that  a  maintenance  programmer  can  easily  grasp  the 
functionality  of  the  Daplex  interface  and  the  relationship  between  it  and  the 
other  portions  of  the  system. 
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We  have  made  every  effort  to  ensure  that  the  C  code  we  have  written 
has  these  characteristics.  For  instance,  w’e  have  avoided  the  use  of  the  shorthand 
notations  available  in  C  and  have  used  the  more  readable,  and  therefor  longer 
version  of  C  whenever  possible.  This  extra  code  has  often  made  the  difference 
between  comprehensible  code  and  cryptic  notations.  Further,  the  interface 
software  does  not  have  any  hidden  side-effects  that  could  pose  problems  months 
or  years  from  now.  As  a  matter  of  fact,  we  have  intentionally  minimized  the 
interaction  between  procedures  to  ease  the  burden  of  maintainability. 

In  addition  to  the  above  software  engineering  techniques,  we  require  pro¬ 
grammers  to  update  documentation  of  the  interface  code  when  changes  are  made. 
Hence,  maintenance  programmers  have  current  documentation  at  all  times,  and 
the  problem  of  trying  to  identify  the  functionality  of  a  program  with  dated  docu¬ 
mentation  is  alleviated.  To  take  the  software  engineering  a  step  further,  the  data 
structures  are  designed  to  be  as  general  as  possible.  Thus,  it  is  an  easy  task  to 
modify  or  rectify  these  structures  to  meet  the  demands  of  an  evolving  system. 

A  final  characteristic  of  a  sound  Daplex  interface  is  extensibility.  A 
software  product  has  to  be  designed  in  a  manner  that  permits  the  easy  modifica¬ 
tion  and  addition  of  code.  In  this  light,  we  have  placed  "stubs”  in  appropriate 
locations  within  KFS  to  permit  easy  insertion  of  the  code  needed  to  handle  multi¬ 
ple  horizontal  screens  of  output. 

C.  THE  DATA  STRUCTURES 

The  Daplex  language  interface  has  been  developed  as  a  single-user  system.  It 
is  recognized  however,  that  at  some  point  in  time  the  Daplex  interface  will  be 
updated  to  a  multi-user  system.  Accordingly,  two  different  concepts  of  data  are 
used  in  the  interface:  (1)  data  structures  shared  by  all  users,  and  (2)  structures 
specific  to  each  user.  In  accordance  with  the  first  data  structure  concept,  the 
Daplex  implementation  has,  whenever  possible,  used  and  added  to  the  existing 
generic  data  structures  generated  by  the  previous  implementations  of  DL/I  and 
SQL.  However,  due  to  the  complexity  of  the  entity-relationship  model,  an  addi¬ 
tional  large  set  of  unique  and  specific  data  structures  was  required  for  the  Daplex 
implementation. 
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Data  Shared  bv  All  Users 


The  following  discussion  of  data  structures  makes  extensive  use  of  the 
university  database  described  in  Figure  3.  A  frequent  reference  to  Figure  3  may 
aid  the  reader  greatly  in  understanding  the  following  material. 

The  data  structures  that  are  shared  by  all  users  are  the  database  schemas 
defined  by  the  users  thus  far.  In  our  case,  these  are  entity-relationship  schemas, 
consisting  of  entities  and  the  relationshipis  (functions)  between  the  entities. 
These  are  not  only  shared  by  all  users,  but  also  shared  by  the  four  modules  of  the 
MLDS,  i.e.,  LIL,  KMS,  KC,  and  KFS.  It  is  important  to  note  that  this  structure 
is  represented  as  a  union  and  is  generic  in  the  sense  that  it  can  be  used  to  sup¬ 
port  the  SQL,  COD.\SYL,  DL/I,  and  Daplex  needs.  Figure  4  depicts  this  data 
structure. 


union  dbid_node 

{ 

struct  rel_dbid_node  *rel; 
struct  hie_dbid _node  *hie; 
struct  net_dbid jtode  *net; 
struct  ent  jdbid_node  *ent; 

} 

Figure  4.  The  dbid_node  Data  Structure. 

The  main  concern  of  this  thesis,  however,  is  with  the  entity-relationship 
model.  In  this  regard,  the  fourth  field  of  this  structure  points  to  a  node  that  con¬ 
tains  the  information  about  an  entity-relationship  database.  Figure  5  illustrates 
this  record. 

The  first  field  is  simply  a  character  array  containing  the  name  of  the 
entity-relationship  database.  The  second  field  contains  a  pointer  to  the  base-type 
nonentity  node,  and  the  following  field  simply  contains  an  integer  value  that 
represents  the  number  of  these  nodes  in  the  database.  The  fourth  field  points  to 
the  entity  node,  and  as  before  the  field  that  immediately  follows  contains  an 
integer  value  representing  the  number  of  such  nodes.  The  sixth  field  contains  a 
pointer  to  the  generalized  entity  supertype  node  and  the  seventh  field  the  integer 
value  of  the  number  of  these  supertypes.  The  eighth  and  tenth  fields  contain 
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struct  ent_dbjd _node 
{ 


char 

edn  name[DBNLength  -t-  l]; 

struct 

ent  non  node  *edn  nonentity; 

int 

edn  num  nonent; 

struct 

ent  node  *edn  entity; 

int 

edn  num  ent; 

struct 

gen  sub  node  *edn  subptr; 

int 

edn  num_gen; 

struct 

sub  non  node  *edn  nonsubptr; 

int 

edn  num  nonsub; 

struct 

der  non  node  *edn  nonderptr; 

int 

edn  num  der; 

struct 

ent  dbid  node  *edn  next  db; 

}; 


Figure  5.  The  ent_dbid_node  Data  Structure, 
pointers  to  the  nonentity  subtypes  and  nonentity  derived  types  respectively,  and 
the  ninth  and  eleventh  fields  contain  the  integer  value  for  the  number  of  such 
nodes.  Finally,  the  twelfth  field  points  to  the  next  entity-relationship  database 
node. 

Figure  6  depicts  the  entity  node  structure.  The  first  field  of  this  struc¬ 
ture  is  a  character  array  which  holds  the  name  of  the  entity,  and  the  second  field 
is  an  integer  representation  of  the  number  of  functions  associated  with  the  entity 
that  this  node  represents.  For  instance,  the  "person”  entity  hais  two  functions 
zissociated  with  it,  "name"  and  "ssn".  The  third  field  is  an  integer  representation 


struct  ent_node 

{ 

char  en^ame[ENLength  +  1]; 
int  en  _num_funct; 

int  en_terminal; 

struct  function_node  *en_ftnptr; 
struct  entjode  *en_next_ent-, 
}; 


Figure  6.  The  ent^ode  Data  Structure. 


of  a  boolean  function  and  indicates  whether  or  not  the  entity  is  a  terminal  type, 
i.e.,  not  a  supertype. 

The  structure  of  the  gen_sub^ode  is  shown  in  Figure  7.  The  first  field, 
similar  to  previous  nodes,  holds  the  name  of  the  generalized  entity  subtypes.  An 
example  applied  to  the  university  data  base  is  ”support_stafr'.  The  second  field 
holds  the  number  of  functions  associated  with  each  entity  subtype,  and  the  third 
field  is  an  integer  representation  of  a  boolean  function  and  holds  a  "1"  if  the 
generalized  entity  is  a  subtype  and  not  a  supertype. 

struct  gen_sub ^ode 

{ 

char  gsn^ame[ENLength  +  1]; 

int  gsn_num_funct; 

int  gsn_terminal; 

struct  overlap _ent ^ode  *gsn_entptr; 

int  gsnjum_ent; 

struct  function  _node  *gsn_ftnptr; 

struct  overlap_sub_node  *gsn_subptr; 

int  gsn_num_sub; 

struct  gen_sub  _node  *gsn  _next_genptr; 

}; 

Figure  7.  The  gen_subj[iode  Data  Structure. 

The  fourth  field  holds  a  pointer  to  the  entity  supertype.  In  the  case  of 
"employee"  the  supertype  is  "person".  The  fifth  field  indicates  the  number  of 
those  entities.  The  sixth  field  holds  a  pointer  to  a  function  associated  with  the 
generalized  subtype,  for  instance,  "salary".  The  seventh  field  holds  a  pointer  to 
the  subtype  supertype.  For  example,  the  supertype  for  the  subtype 
"support_stafr'  is  "employee".  The  eighth  field  maintains  a  record  of  the 
number  of  such  subtype  supertypes.  The  final  field  simply  points  to  the  next 
gen  _sub  _node. 

The  ent_non_node  record  is  shown  in  Figure  8,  and  contains  information 
about  each  nonentity  base-type  in  the  database.  The  first  field  of  the  record 
holds  the  name  of  the  nonentity  node,  for  example,  "rank_name".  The  second 
field  holds  the  character  that  indicates  the  type  of  nonentity  node,  either  "i". 
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integer;  "e",  enumeration;  "f,  floating  point;  "s”,  string;  "b",  boolean.  The  next 
field  contains  an  integer  that  indicates  the  maximum  length  of  the  base-type 
value. 

The  fourth  field  contains  an  integer  representation  of  a  boolean  value,  a 
"1"  or  "0",  that  indicates  whether  or  not  there  is  a  range  associated  with  the 
nonentity  node.  For  example,  the  nonentity  "grade_point''  has  a  range  of  0.0  to 
4.0,  while  "rank-name"  is  without  a  range.  The  fifth  field  contains  an  integer  that 
represents  the  number  of  different  values  that  the  nonentity  can  assume.  As  an 
example,  both  "rank_name"  and  "semester^name"  can  assume  three  values,  but 
"grade_point"  can  assume  40  different  values. 

struct  ent^on^ode 

{ 

char  enn_name[ENIiength  +  l); 

char  enn_type; 

int  enn_totaHength; 

int  enn_range; 

int  enn  _num_values; 

struct  ent_value  *enn_yalue; 

int  enn_constant; 

struct  ent_non_node  *enn_next_node; 

}: 

Figure  8.  The  ent _non _node  Data  Structure 

The  sixth  field  contains  a  pointer  to  the  actual  value  of  the  base-type, 
and  the  seventh  field  contains  an  integer  representation  of  a  boolean  value  that 
indicates  if  the  actual  value  of  the  base-type  is  a  constant.  There  are  no  con¬ 
stants  in  the  university  database,  but,  as  an  example,  the  value  of  the  base-type 
could  assume  the  constant  value  of  pi  (3.14159265)  or  Avogadro’s  number  (6.023 
X  10 '23).  The  eighth  and  final  field  contains  a  pointer  to  the  next  nonentity 
node. 

The  subjnon^ode  is  shown  in  Figure  9.  This  structure  is  almost  identi¬ 
cal  in  form  and  similar  in  purpose  to  the  ent_non_node  of  Figure  6.  The  main 
difference  in  purpose  between  the  two  structures  is  that  the  ent_non_node  is  for  a 
base-type  nonentity  and  the  sub_non_node  is  for  a  subtype  nonentity.  The 
difference  in  form  between  the  two  structures  is  the  absence  of  constants  in  the 


struct  sub^on^ode 

{ 

char  snn_naine[ENLength  +  l]; 

char  snn_type; 

int  snn_total_l^ength; 

int  snn_range; 

int  snn^um_values; 

struct  ent_value  *snn_value; 

struct  sub_non  jode  *snn  _next_node; 

}; 

Figure  9.  The  sub^on_node  Data  Structure. 
sub_non jiode.  Maintaining  two  separate  constant  lists  would  be  redundant, 
hence  the  constants  are  found  only  in  the  ent^on_node. 

The  next  node,  similar  to  both  the  ent_non^ode  and  the  sub_non_node, 
is  the  der _non _node,  shown  in  Figure  10.  The  der _non _node  is  identical  in  struc¬ 
ture  to  the  sub^on^ode  and  differs  in  function  in  that  it  applies  to  the  derived 
nonentity  subtypes. 


struct  der_non  jiode 

{ 

char  dnn_name[FiNLength  -|-  l]; 

char  dnn_type; 

int  dnn_totaMength; 

int  dnnjrange; 

int  dnn  _num_values; 

struct  ent_yalue  *dnn_value; 
struct  derjon^ode  *dnn^ext_node; 
}; 


Figure  10.  The  der^on^ode  Data  Structure. 

The  final  node  that  we  will  discuss  is  this  section  is  the  function_node, 
shown  in  Figure  11.  The  function ^ode  defines  the  structures  for  each  function 
type  declaration.  As  an  example,  the  function  "dept"  returns  the  entity 
"department”  when  applied  to  the  entity  "faculty". 

The  first  field  of  the  function_node  points  to  the  name  of  the  function,  in 
this  example  the  name  is  "dept".  The  second  field  holds  the  type,  an  "e"  in  this 
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struct  functionjQode 
{ 


char 

fn  namejENLength+l]; 

char 

fn  type; 

int 

fn  range; 

int 

fr  total  length; 

int 

fn  num  value; 

struct 

ent  value  *fn  value; 

struct 

ent  node  *fn  entptr; 

struct 

gen  sub  node  *fn  subptr; 

struct 

ent  non  node  *fn  nonentptr; 

struct 

sub  non  node  *fn  nonsubptr; 

struct 

der  non  node  *fn  nonderptr; 

int 

fn  entnull; 

int 

fn  unique; 

struct 

function  node  *fn  next  fntptr; 

}; 

Figure  11.  The  function  jode  Data  Structure, 
case.  The  third  field  indicates  when  the  function  has  a  range  of  values,  the  fourth 
field  indicates  the  length  and  the  fifth  field  indicates  the  number  of  values,  if  any. 
In  this  example,  all  three  fields  would  hold  a  "0”. 

The  sixth  field  would  hold  the  actual  value,  if  there  were  any,  and  the 
next  five  fields  hold  pointers  to  the  type  to  which  a  particular  function  belongs. 

function  may  belong  to  more  than  one  type,  but  it  is  extremely  unlikely  that  it 
would  belong  to  all  five.  In  our  example,  the  function  "dept"  belongs  to  only  one 
type,  the  entity  "department",  hence  only  the  ent_node  pointer,  fn_entptr,  will 
contain  any  information,  the  remaining  four  type  field  pointers  will  be  empty. 

The  twelfth  field  indicates  if  there  is  an  associated  entity  value.  It  is  ini¬ 
tialized  to  hold  a  "0"  and  in  the  above  example  maintains  that  "0".  The  thir¬ 
teenth  field  indicates  whether  or  not  the  function  is  unique.  It  too  is  initialized 
to  "0",  and  in  our  example  maintains  that  "0".  The  final  field  simply  contains  a 
pointer  to  the  next  function. 

2.  Data  Specific  to  Each  User 

This  category  of  data  represents  information  required  to  support  each 


user’s  particular  interface  needs.  The  data  structures  used  to  accomplish  this 


may  be  thought  of  zis  forming  a  hierarchy.  At  the  root  of  this  hierarchy  is  the 
user_info  record,  shown  in  Figure  12,  which  maintains  information  on  all  current 
users  of  a  particular  language  interface.  The  user_info  record  holds  the  ID  of  the 
user,  a  union  that  describes  a  particular  interface,  and  a  pointer  to  the  next  user. 
The  union  field  is  of  particular  interest  to  us.  As  noted  earlier,  a  union  serves  ^ls 
a  generic  data  structure. 

struct  user^nfo 

{ 

char  uid[UIDLength  +  1]; 

union  li_i^nfo  li_type; 
struct  user^nfo  *next_user; 

} 

Figure  12.  The  user^nfo  Data  Structure. 

In  this  case,  the  union  may  hold  the  data  for  a  user  accessing  either  an 
SQL  language  interface  layer,  a  DL/I  LIL,  a  CODASYL-DML  LIL,  or  a  Daplex 
LIL.  The  li_info  union  is  shown  in  Figure  13. 

We  are  only  interested  in  the  data  structures  containing  user  information 
that  pertain  to  Daplex,  or  entity-relationship,  language  interface.  This  structure 
is  referred  to  as  dap_info  and  is  depicted  in  Figure  14.  The  first  field  of  this 
structure,  dpi_curr_db,  is  itself  a  record  and  contains  currency  information  on  the 
database  being  accessed  by  a  user.  The  second  field,  dpi_file,  is  also  a  record. 
The  file  record  contains  the  file  descriptor  and  file  identifier  of  a  file  of  Daplex 
transactions,  either  requests  or  database  descriptions.  The  next  field, 
dpi_dml_tran,  is  also  a  record,  and  holds  information  that  describes  the  Daplex 

union  li^nfo 

{ 

struct  sqMnfo  li_sql; 
struct  dli_info  li_dli; 
struct  dmHnfo  li_dml,’ 
struct  dap_info  li_dap; 

) 


Figure  13.  The  li_info  Data  Structure. 


struct  dap_info 

{ 


struct 

curr  _db_info 

dpi_curr_db; 

struct 

file_info 

dpi_file; 

struct 

tran  info 

dpi  dml  tran; 

int 

dap  operation; 

struct 

ddl  info 

*dpi  ddl  files; 

union 

kms  info 

dpi  kms  data: 

union 

kfs  info 

dpi  kfs  data; 

union 

kc  info 

dpi  kc  data; 

int 

dap  error; 

int 

dap  answer; 

int 

dap  buff  count; 

}; 

Figure  14.  The  dap_info  Data  Structure, 
transactions  to  be  processed.  This  includes  the  number  of  requests  to  be  pro¬ 
cessed,  the  first  request  to  be  processed,  and  the  current  request  being  processed. 
The  fourth  field  of  the  dap_j^nfo  record,  dap _operation,  is  a  flag  that  indicates  the 
operation  to  be  performed.  This  may  be  either  the  loading  of  a  new  database,  or 
the  execution  of  a  request  against  an  existing  database.  The  next  field, 
dpi_ddl  Jiles,  is  a  pointer  to  a  record  describing  the  descriptor  and  template  files. 
These  files  contain  information  about  the  ABDL  schema  corresponding  to  the 
current  entity-relationship  database  being  processed,  i.e.,  the  ABDL  schema 
information  for  a  newly  defined  entity-relationship  databeise.  The  following 
fields,  dpi ^ms_data,  dpi_kfs_data  and  dpi _kc_data,  are  unions  that  contain 
information  required  by  the  KMS,  KFS  and  KC,  respectively.  These  are 
described  in  more  detail  in  later  chapters.  The  next  field,  error,  is  an  integer 
value  representing  a  specific  error  type.  The  next  field,  answer,  is  used  by  the 
LIL  to  record  answers  received  through  its  interaction  with  the  user  of  the  inter¬ 
face.  The  last  field,  buff_count,  is  a  counter  variable  used  in  the  KC  to  keep 
track  of  the  result  buffers. 


D.  THE  ORGANIZATION  OF  THE  NEXT  FOUR  CHAPTERS 

The  following  four  chapters  are  meant  to  provide  the  user  with  a  more 
detailed  analysis  of  the  modules  constituting  MLDS  and  Daplex  implementations. 
Each  chapter  begins  with  aji  overview  of  what  each  particular  module  does  and 
how  it  relates  to  the  other  modules.  The  actual  processes  performed  by  each 
module  are  then  discussed.  This  includes  a  description  of  the  actual  data  struc¬ 
tures  used  by  the  modules.  Each  chapter  concludes  with  a  discussion  of  module 
shortcomings. 


III.  STORAGE  AND  RETRIEVAL  OF  THE  DAPLEX  SCHEMAS 


The  first  modules  that  we  discuss  concern  the  storage  of  the  Daplex  schemas 
from  memory  and  the  recreation  of  those  schemas  in  memory  from  a  file.  It  is 
understood  that  these  modules  are  not  as  conceptually  interesting  as  the  LIL, 
KMS,  KC  or  KFS,  but  they  are  important,  and  are  included  here  for 
completeness. 

The  reader  is  reminded  that  Appendix  B  contains  the  modules  for  storage 
and  retrieval  and  should  be  consulted  frequently  to  ensure  a  thorough  under¬ 
standing  of  this  chapter. 

A.  DAPLEX  SCHEMA  STORAGE 

Early  in  the  design  phase  of  the  storage  module,  we  realized  that  several 
items  in  the  schema  could  be  stored  more  than  once  and  storage  space  unneces¬ 
sarily  wasted.  Accordingly,  we  made  a  concerted  effort  to  avoid  storing  redun¬ 
dant  data  and  mapped  the  data  to  the  correct  structure  with  the  use  of  pointers. 

The  Daplex  schemas  are  tied  together  ais  they  are  written  to  a  file  by  a  series 
of  pointer  manipulations.  The  pointer  that  is  responsible  for  each  ent_dbid_node, 
hence  for  the  entire  Daplex  database,  is  known  as  db_ptr.  Generally,  the  db_ptr 
is  set  to  the  head  of  the  database  and  then  passed  to  the  routine  responsible  for 
writing  the  contents  of  that  specific  portion  of  the  ent_dbid_node  to  a  file. 
Accordingly,  the  entire  ent_dbid_node  is  not  written  to  the  file  at  this  time, 
rather,  only  the  database  name,  edn_name,  and  the  number  of  nonentities, 
edn _num_nonent,  are  stored,  (see  Figure  5  again)  In  general,  as  the  pointer  is 
sequenced  through  the  node,  each  structure  it  encounters  is  processed  in  turn, 
storing  necessary  information  while  at  the  same  time  avoiding  information  that 
may  be  previously  stored  in  another  node. 

The  first  structure  that  the  pointer  encounters  is  the  ent_non_node  (as  in 
Figure  5).  The  routine  for  storing  the  nonentity  nodes  is  known  as 
proc_ent _non _node.  The  entire  nonentity  node  is  stored  at  this  time,  (see  Figure 
8  again)  including  any  associated  entity  values,  as  this  information  is  not 


duplicated  elsewhere.  The  pointer  in  the  calling  routine  then  moves  to  the  next 
nonentity  node  and  the  entire  procedure  is  repeated.  This  process  continues  until 
all  the  nonentity  nodes  have  been  stored. 

The  dbjptr,  is  then  set  to  the  entity  nodes  (as  in  Figure  5),  the  procedure 
for  processing  the  entity  nodes,  wr_ent_node,  is  executed,  and  the  entire  set  of 
entity  nodes  is  processed,  (see  Figure  6  again)  However,  the  functions  associated 
with  the  respective  entities  are  not  processed,  as  all  the  functions  are  handled 
separately. 

The  routine  wr_gen_sub ^ode,  processes  the  next  node,  the  generalized  entity 
subtypes.  Only  the  first  three  fields,  gsn_name,  gsn_num_funct,  and 
gsn_terminal,  (see  Figure  7  again)  are  stored  directly  by  this  routine,  the  remain¬ 
ing  fields  are  stored  immediately  after  execution  of  wr_gen_sub _node,  and  within 
the  main  routine. 

The  remainder  of  the  gen_sub _node  is  processed  in  the  main  routine.  This 
segment  of  code  is  handled  in  the  main  routine  instead  of  in  a  separate  procedure 
because  the  pointer  manipulations  are  more  easily  handled  here  and  because  this 
data  is  processed  only  once,  a  separate  routine  was  not  considered  necessary. 
The  reader  should  note  that  the  subtypes  with  entity  supertypes,  i.e.,  the 
overlap_ent_nodes,  and  the  terminal  subtypes  that  define  one  or  more  subtypes, 
i.e.,  the  overlap_sub_nodes,  that  are  eissociated  with  the  gen_sub_node  are  all 
processed  at  this  time. 

The  subtype  nonentity  nodes  are  processed  within  the  proc_sub_non_node 
routine.  First,  the  db_ptr  is  set  to  point  at  the  edn_nonsubptr  (eis  in  Figure  5). 
The  proc_sub^on^ode  is  then  called,  and  the  entire  sub_non_node  is  stored. 

The  derived  type  nonentity  nodes  are  processed  in  exactly  the  same  manner 
Eis  the  sub_non_node.  The  db_ptr  is  set  to  point  at  ednjnonderptr  (as  in  Figure 
5)  and  the  entire  der^on^ode  is  processed,  (see  Figure  10  again) 

The  functions  associated  with  the  entity  nodes  are  the  next  items  stored.  The 
reader  may  remember  that  we  chose  not  to  store  these  functions  earlier.  We 
store  the  functions  now  by  first  setting  the  db_ptr  to  point  at  the  entity  nodes 
and  then  call  wr  _all_ent  _node,  a  routine  that  calls  a  second  routine, 
proc_function_node,  that  processes  all  of  the  functions. 
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The  proc_function_node  routine  tracks  sequentially  through  the  appropriate 
function  node  (see  Figure  11  again)  and  stores  data  for  every  field.  Since  the 
ent_node,  gen_sub_node,  ent_non_node,  sub_non_node  and  der_non_node  (as  in 
Figure  5)  may  or  may  not  have  data  aasociated  with  them,  we  have  chosen  to 
place  a  " ' "  in  the  empty  fields  to  maintain  the  integrity  of  the  database. 

The  functions  associated  with  the  gen_sub _nodes  (as  in  Figure  7)  are  stored 
in  a  manner  very  similar  to  the  process  just  described.  The  db_ptr  is  set  to  point 
at  the  gen_sub^ode  and  once  again  the  proc_function_node  routine  is  called. 

At  this  point  the  database  for  one  ent _dbid_node  has  been  stored.  The  pro¬ 
gram  checks  to  see  if  any  more  entjdbid^odes  remain  to  be  stored.  If  so,  the 
above  procedures  are  repeated.  If  not,  a  is  inserted  at  the  end  of  the  data¬ 
base  as  an  end  of  database  marker. 

B.  RETRIEVAL  OF  THE  DAPLEX  SCHEMA 

The  process  for  retrieving  the  Daplex  schemas  from  secondary  storage  and 
loading  them  into  memory  is  almost  a  reverse  of  the  storage  procedure.  Different 
structures  are  used,  as  the  save  module  was  written  by  one  member  of  the  team 
and  the  retrieval  module  by  the  other;  otherwise,  the  process  is  bzisically  a 
reversal. 

The  routine  that  reads  data  into  the  first  Daplex  database,  i.e.,  the  first 
ent_dbid^ode,  is  rd_ent_dbid_node.  The  memory  is  first  allocated,  the  pointers 
nulled,  and  then  the  first  two  fields,  edn_name  and  edn_num_nonent,  (as  in  Fig¬ 
ure  5)  are  loaded  into  memory.  The  remaining  fields  are  loaded  in  order  along 
with  the  respective  field  data. 

The  pointer  sequences  to  the  next  allocated  space  in  memory  and  the  routine 
that  reads  in  the  data  for  the  nonentity  nodes,  rd_ent_non^ode,  is  executed  (as 
in  Figure  8).  As  before,  the  entire  nonentity  node  is  processed  at  one  time. 

The  next  structures  to  be  filled,  at  least  partially,  are  the  entity  nodes  (as  in 
Figure  6).  As  with  wr_ent_node,  the  functions  associated  with  rd_ent_node,  and 
therefore  the  entities,  are  processed  later. 

The  generalized  entity  subtypes  are  the  next  nodes  to  be  processed.  As  with 
the  storage  routine,  only  three  of  the  fields  gsnjuame,  gsn_num_funct  and 
gsn_terminal,  are  processed  in  rd_gen_sub_node  (as  in  Figure  7).  However, 
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unlike  the  storage  routine,  the  remainder  of  the  gen_sub^ode  is  handled  in  two 
smaller  routines,  rd_overlap_ent_node  and  rd_overlap_sub_node. 

After  the  first  three  fields  of  the  generalized  subtypes  are  processed,  the 
pointer  is  sequenced  and  the  routine  that  handles  the  subtypes  with  one  more 
entity  supertypes,  rd_overlap _ent _node,  is  executed.  The  rd _overlap_ent _node 
routine  checks  for  the  presence  of  subtypes  with  one  or  more  supertypes  and  then 
loads  those  names  into  memory.  The  routine  rd_overlap_sub_node  functions 
exactly  2is  rd_overlap_ent_node,  but  on  the  subtype  supertypes. 

After  the  overlap  nodes  are  processed,  the  pointer  sequences  and  the  subtype 
nonentity  nodes  are  allocated  and  filled.  This  process  occurs  within  the 
rd^ub_non^ode  routine  (as  in  Figure  9). 

The  derived  type  nonentity  nodes  (as  in  Figure  10)  are  processed  in  exactly 
the  same  manner  as  the  sub_non^ode.  The  pointer  is  sequenced,  the  memory 
allocated,  and  data  entered  in  exactly  the  same  fashion.  The  functions  associated 
with  the  entity  nodes  are  the  next  items  loaded  into  memory.  The  functions  are 
loaded  by  first  sequencing  the  pointer  and  then  calling  the  routine  responsible  for 
loading  the  functions,  rd_function^ode.  The  rd_function_node  routine,  along 
with  the  previous  routines,  first  allocates  the  necessary  memory  and  then  nulls 
the  appropriate  pointers.  The  routine  then  tracks  through  the  function  node  (as 
in  Figure  11)  and  loads  those  fields  with  data.  Since  it  is  possible  for  any  of  the 
ent_nodes,  gen_sub_nodes,  ent_non_nodes,  sub_non_nodes  or  der_non_nodes  to 
be  without  data,  the  routine  first  checks  those  nodes  to  see  if  they  contain  a  "  * 
the  symbol  for  an  empty  node.  Finally,  the  module  checks  to  see  if  it  has  encoun¬ 
tered  a  the  symbol  for  end  of  database.  If  so,  all  processes  are  terminated. 

We  have  written  a  small  main  routine  that  first  executes  the  retrieval  of  an 
existing  database  and  then  executes  the  saving  of  that  database  to  a  file.  The 
main  routine  calls  the  two  modules  previously  discussed  and  then  executes  a 
print  statement  for  every  retrieval  and  save  action.  This  methodology  has  allowed 
the  authors  to  more  effectively  debug  the  programs. 


IV.  THE  LANGUAGE  INTERFACE  LAYER  (LIL 


The  second  set  of  modules  that  we  will  discuss  concern  LIL,  the  first  modules 
in  the  Daplex  mapping  process.  LIL  is  used  to  control  the  order  in  which  the 
other  modules  are  called,  and  allows  the  user  to  input  transactions  from  either  a 
file  or  the  terminal.  A  transaction  may  take  the  form  of  either  a  database 
description  (DBD)  of  a  new  database,  or  a  Daplex  request  against  an  existing 
database.  .\  single  transaction  may  contain  multiple  requests,  allowing  a  group 
of  requests  to  perform  a  single  task.  For  example,  several  "atomic"  statements, 
those  statements  that  are  executed  as  an  indivisible  action  with  respect  to  the 
database,  could  be  executed  together  as  a  single  transaction. 

The  mapping  process  occurs  when  LIL  sends  a  single  transaction  to  KMS. 
After  the  transaction  has  been  received  by  KMS,  KC  is  called  to  process  the 
transaction.  Control  always  returns  to  LIL,  where  the  user  may  either  continue 
with  another  transaction  or  close  the  session  by  exiting  to  the  operating  system. 

LIL  is  menu-driven,  and  when  the  transactions  are  read  from  either  a  file  or 
the  terminal,  they  are  stored  in  the  dap_req_mfo  data  structure.  If  the  transac¬ 
tions  are  database  descriptions,  they  are  sent  to  the  KMS  in  sequential  order.  If 
the  transactions  are  Daplex  requests,  the  user  is  prompted  by  another  menu  to 
selectively  choose  an  individual  request  to  be  processed.  The  menus  provide  an 
easy  and  efficient  way  for  the  user  to  view  and  select  the  methods  of  request  pro¬ 
cessing  desired.  Each  menu  is  tied  to  its  predecessor,  so  that  by  exiting  one 
menu  the  user  is  moved  up  the  "menu  tree".  This  allows  the  user  to  perform 
multiple  tasks  in  one  session. 

A.  THE  LIL  DATA  STRUCTURES 

LIL  uses  three  data  structures  to  store  the  user’s  transactions  and  control  the 
transaction  sent  to  KMS.  It  is  important  to  note  that  these  data  structures  are 
shared  by  both  LIL  and  KMS. 

The  first  data  structure  is  named  tran_info  and  is  shown  in  Figure  15.  The 
first  field  of  this  record,  ti  first  req,  is  the  pointer  to  the  first  request  data 


struct  tran_info 

{ 

union  req^nfo  ti  _first_req; 
union  req^nfo  ti_curr_req; 

int  ti^o_req; 

}; 

Figure  15.  The  tran_info  Data  Structure, 
structure  that  contains  the  union  of  all  the  language  requests  of  MLDS 
(see  Figure  16).  The  first  request  can  originate  from  either  a  file  or  a  terminal. 
The  second  field  of  tran_^nfo  is  a  pointer  to  the  current  transaction,  set  by  LIL  to 
tell  the  KMS  the  precise  transaction  to  process  next.  The  third  field  contains  the 
number  of  transactions  currently  in  the  transaction  list.  This  number  is  used  for 
loop  control  when  printing  the  transaction  list  to  the  screen,  or  when  searching 
the  list  for  a  transaction  to  be  executed. 

The  second  data  structure  used  by  LIL,  req^nfo,  is  a  union  of  the  language 
requests  of  MLDS,  and  is  shown  in  Figure  16.  It  serves  a  routing  control  func¬ 
tion,  in  that  it  routes  a  transaction  request  to  the  appropriate  database  language. 
In  this  thesis,  we  are  concerned  only  with  the  the  fourth  field  of  this  structure, 
which  contains  a  pointer  to  the  dap_req^nfo  data  structure  (see  Figure  17),  each 
copy  representing  a  Daplex  user  transaction. 

The  third  data  structure  used  by  LIL  is  named  dap_req_info.  Each  copy  of 
this  record  represents  a  user  transaction,  and  thus,  is  an  element  of  the  transac¬ 
tion  fist.  The  dap_req_info  data  structure  is  shown  in  Figure  17.  The  first  field 

union  req_info 

{ 

struct  rel_req_info  *ri_rel_req; 
struct  hie_req_mfo  *ri  _hie_req; 

struct  net_req_info  *ri_net_req; 

struct  dap_req_info  *ri_dap_req; 

struct  ab_req_mfo  *ri  _ab_req; 

}; 

Figure  16.  The  req  info  Data  Structure. 


struct  dap_req_info 

{ 

char  *dap_£eq; 

inc  dap^eq_len; 
struct  temp_str_info  ’'‘dap_in_req; 

struct  dap_req_mfo  *dap_sub_req; 

struct  dap^eq_info  *dap_next_req; 

}; 

Figure  17.  The  dap_req_info  Data  Structure, 
of  this  record,  dap_req,  is  a  character  string  that  contains  the  actual  Daplex 
transaction.  The  second  field,  dap_req^en,  contains  the  length  of  the  transac¬ 
tion.  It  is  used  to  allocate  the  exact,  and  therefore  minimal,  amount  of  memory 
space  for  the  transaction.  The  third  field,  dap_i^n_req,  is  a  pointer  to  a  list  of 
character  arrays  that  each  contain  a  single  line  of  one  transaction.  After  all  lines 
of  a  transaction  have  been  read,  the  line  list  is  concatenated  to  form  the  actual 
transaction,  dap_req.  If  a  transaction  contains  multiple  requests,  the  fourth  field, 
dap_sub_req,  points  to  the  list  of  requests  that  make  up  the  transaction.  In  this 
case,  the  field  dap_in_req  is  the  first  request  of  the  transaction.  The  last  field, 
dap_next_req,  is  a  pointer  to  the  next  transaction  in  the  list  of  transactions. 

B.  FUNCTIONS  AND  PROCEDURES 

LIL  makes  use  of  a  number  of  functions  and  procedures  in  order  to  create  the 
transaction  list,  pass  elements  of  the  list  to  KMS,  and  maintain  the  database 
schemas.  We  do  not  describe  each  of  these  functions  and  procedures  in  detail. 
Rather,  we  provide  a  general  description  of  the  LIL  processes. 

1.  Initialization 

The  MLDS  is  designed  to  be  able  to  accommodate  multiple  users,  but  in 
this  version  it  is  implemented  to  support  only  a  single  user.  To  facilitate  the 
transition  from  a  single-user  system  to  a  multiple-user  system,  each  user  possesses 
his  own  copy  of  a  user  data  structure  when  entering  the  system.  This  user  data 
structure  stores  all  of  the  relevant  data  that  the  user  may  need  during  their  ses¬ 
sion.  All  four  modules  of  the  language  interface  make  use  of  this  structure.  The 
modules  use  many  temporary  storage  variables,  both  to  perform  their  individual 


tasks,  and  to  maintain  common  data  between  modules.  The  transactions,  in  user 
data  language  form,  and  mapped  kernel  data  language  form,  are  also  stored  in 
each  user  data  structure.  It  is  easy  to  see  that  the  user  structure  provides  conso¬ 
lidated,  centralized  control  for  each  user  of  the  system.  When  a  user  logs  onto 
the  system,  a  user  data  structure  is  allocated  and  initialized.  The  user  ID 
becomes  the  distinguishing  feature  to  locate  and  identify  different  users.  The 
user  data  structures  for  all  users  are  stored  in  a  linked-list.  When  new  users 
enter  the  system,  their  user  data  structures  are  appended  to  the  end  of  the  list. 
In  our  current  environment  there  is  only  a  single  element  on  the  user  list.  In  a 
future  environment,  when  there  are  multiple  users,  we  simply  expand  the  user  list 
as  described  above. 

2.  Creating  the  Transaction  List 

There  are  two  operations  the  user  may  perform.  A  user  may  define  a 
new  database  or  process  Daplex  requests  against  an  existing  database.  The  first 
menu  that  is  displayed  prompts  the  user  to  select  the  operation  desired.  Each 
operation  represents  a  separate  procedure  to  handle  specific  circumstances.  The 
menu  looks  like  the  following: 

Enter  type  of  operation  desired 
(1)  -  load  a  new  database 
(p)  -  process  old  database 
(x)  -  return  to  the  operating  system 
ACTION  — >  _ 

For  either  choice  (i.e.,  1  or  p),  another  menu  is  displayed  to  the  user 
requesting  the  mode  of  input.  This  input  may  always  come  from  a  data  file.  If 
the  operation  selected  from  the  previous  menu  had  been  "p”,  then  the  user  may 
also  input  transactions  interactively  from  the  terminal.  The  generic  menu  looks 
like  the  following: 
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Enter  mode  of  input  desired 

(f)  -  read  in  a  group  of  transactions  from  a  Ple 
(t)  -  read  in  transactions  from  the  terminal 
(x)  -  return  to  the  previous  menu 
ACTION  — >  _ 

Note  that  the  choice  "t"  would  be  omitted  if  the  operation  selected  from  the  pre¬ 
vious  menu  had  been  to  load  a  new  database.  Again,  each  mode  of  input  selected 
corresponds  to  a  different  procedure  to  be  performed.  The  transaction  list  is 
created  by  reading  from  the  file  or  terminal,  looking  for  an  end-of-transaction 
marker  or  an  end-of-file  marker.  These  flags  tell  the  system  when  one  transaction 
has  ended,  and  when  the  next  transaction  begins.  When  the  list  is  being  created, 
the  pointers  to  access  the  list  are  initialized.  These  pointers,  ti_first_req  and 
ti_curr_req  (as  in  Figure  15)  are  set  to  the  first  transaction  read,  in  other  words, 
to  the  head  of  the  transaction  list. 

3.  Accessing  the  Transaction  List 

Since  the  transaction  list  stores  both  DBDs  and  Daplex  requests,  two 
different  access  methods  have  to  be  employed  to  send  the  two  types  of  transac¬ 
tions  to  the  KMS.  We  discuss  the  two  methods  separately.  In  both  cases,  the 
KMS  accesses  a  single  transaction  from  the  transaction  list.  It  does  this  by  read¬ 
ing  the  transaction  pointed  to  by  the  request  pointer,  ti_curr_req,  of  the 
tran^nfo  data  structure  (as  in  Figure  15).  Therefore,  it  is  the  job  of  LIL  to  set 

this  pointer  to  the  appropriate  transaction  before  calling  KMS. 


a.  Sending  DBDs  to  KMS  -  When  the  user  specifies  the 
filename  of  DBDs  (input  from  a  file  only),  further 
user  intervention  is  not  required.  To  produce  a  new 
databeise,  the  transaction  list  of  DBDs  is  sent  to  KMS 
via  a  program  loop.  This  loop  traverses  the  transaction 
list,  calling  KMS  for  each  DBD  in  the  list. 

b.  Sending  Daplex  Requests  to  KMS  -  In  this  case,  after 

the  user  has  specified  the  mode  of  input,  the  user  conducts 
an  interactive  session  with  the  system.  First,  all  Daplex 
requests  are  listed  to  the  screen.  As  the  requests  are 
listed  from  the  transaction  list,  a  number  is  sissigned  to 
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each  transaction  in  ascending  order,  starting  with  the  number 
one.  The  number  appears  on  the  screen  to  the  left  of  the 
first  line  of  each  transaction.  Note  that  each  transaction 
may  contain  multiple  requests.  Next,  an  access  menu  is 
displayed  which  looks  like  the  following: 


Pick  the  number  or  letter  of  the  action  desired 

(num)  -  execute  one  of  the  preceding  transactions 
(d)  -  redisplay  the  list  of  transactions 

(r)  -  reset  the  currency  pointer  to  the  root 

(x)  -  return  to  the  previous  menu 

ACTION  — >  _ 

Since  Daplex  requests  are  independent  items,  the  order  in  which  they  are 
processed  does  not  matter.  The  user  has  the  option  of  executing  any  number  of 
Daplex  requests.  A  loop  causes  the  menu  to  be  redisplayed  after  any  Daplex 
request  has  been  executed  so  that  further  choices  may  be  made.  The  selection 
"r"  causes  the  currency  pointer  to  be  repositioned  to  the  root  of  the  entity- 
relationship  schema  so  that  subsequent  requests  may  access  the  complete  data¬ 
base,  rather  than  be  limited  to  beginning  from  a  current  position  established  by 
previous  requests. 

4.  Calling  the  KC 

As  mentioned  earlier,  LIL  acts  as  the  control  module  for  the  entire 
system.  When  KMS  has  completed  its  mapping  process,  the  transformed  transac¬ 
tions  have  to  be  sent  to  KC  to  interface  with  the  kernel  database  system.  For 
DBDs,  KC  is  called  after  all  DBDs  on  the  transaction  list  have  been  sent  to 
KMS.  The  mapped  DBDs  have  been  placed  in  a  mapped  transaction  list  that 
KC  is  going  to  access.  Since  Daplex  requests  are  independent  items,  the  user 
should  wait  for  the  results  from  one  Daplex  request  before  issuing  another. 
Therefore,  after  each  Daplex  request  has  been  sent  to  KMS,  KC  is  immediately 
called.  The  mapped  Daplex  requests  are  placed  on  a  mapped  transaction  list, 
which  KC  may  easily  access. 

5.  W^rapping-up 

Before  exiting  the  system,  the  user  data  structure  described  in  Chapter  II 
(as  in  Figure  12)  has  to  be  deallocated.  The  memory  occupied  by  the  user  data 


V.  THE  KERNEL  MAPPING  SYSTEM  (KMS 


KMS  is  the  second  module  in  the  Daplex  mapping  interface  and  is  called 
from  the  language  interface  layer  (LIL)  when  LIL  has  received  Daplex  requests 
input  by  the  user.  The  function  of  KMS  is  to;  (1)  parse  the  request  to  validate 
the  user’s  Daplex  syntax,  (2)  translate,  or  map,  the  request  to  an  equivalent 
ABDL  request,  and  (3)  perform  a  semantic  analysis  of  the  current  ABDL  request 
generated  relative  to  the  request  generated  during  a  previous  call  to  KMS.  Once 
an  appropriate  ABDL  request,  or  set  of  requests,  has  been  formed,  it  is  made 
available  to  the  kernel  controller  (KC)  which  then  prepares  the  request  for  execu¬ 
tion  by  MBDS.  KC  is  discussed  in  Chapter  VI. 

A.  AN  OVERVIEW  OF  THE  MAPPING  PROCESS 

From  the  description  of  the  KMS  functions  above  we  immediately  see  the 
requirement  for  a  parser  as  a  part  of  the  KMS.  This  parser  validates  the  Daplex 
syntax  of  the  input  request.  The  parser  grammar  is  the  driving  force  behind  the 
entire  mapping  system. 

1.  The  KMS  Parser  /  Translator 

The  KMS  parser  has  been  constructed  by  utilizing  Yet-Another-Compiler 
Compiler  (YACC)  [Ref.  17].  YACC  is  a  program  generator  designed  for  syntac¬ 
tic  processing  of  token  input  streams.  Given  a  specification  of  the  input  language 
structure  (a  set  of  grammar  rules),  the  user’s  code  to  be  invoked  when  such  struc¬ 
tures  are  recognized,  and  a  low-level  input  routine,  YACC  generates  a  program 
that  syntactically  recognizes  the  input  language  and  allows  invocation  of  the 
user’s  code  throughout  this  recognition  process.  The  class  of  specifications 
accepted  is  a  very  general  one:  LALR(l)  grammars.  It  is  important  to  note  that 
the  user’s  code  mentioned  above  is  our  mapping  code  that  is  going  to  perform  the 
Daplex-to-ABDL  translation.  As  the  low-level  input  routine,  we  utilize  a  Lexical 
Analyzer  Generator  (LEX)  [Ref.  18] .  LEX  is  a  program  generator  designed  for 
lexical  processing  of  character  input  streams.  Given  a  regular-expression 
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desc’-iption  of  the  input  strings,  LEX  generates  a  program  that  partitions  the 
input  stream  into  tokens  and  communicates  these  tokens  to  the  parser. 

The  parser  produced  by  YACC  consists  of  a  finite-state  automaton  with 
a  stack  that  performs  a  top-down  parse,  with  left-to-right  scan  and  a  one  token 
look-ahead.  Control  of  the  parser  begins  initially  with  the  highest-level  grammar 
rule.  Control  descends  through  the  grammar  hierarchy,  calling  lower  and  lower- 
level  grammar  rules  while  searching  for  appropriate  tokens  in  the  input.  As  the 
appropriate  tokens  are  recognized,  some  portions  of  the  mapping  code  are 
invoked  directly.  In  other  c2Lses,  tokens  are  propagated  upwards  through  the 
grammar  hierarchy  until  a  higher-level  rule  has  been  satisfied,  and  a  further 
translation  is  performed.  When  all  of  the  necessary  lower-level  grammar  rules 
have  been  satisfied  and  control  has  ascended  to  the  highest-level  rule,  the  parsing 
and  translation  processes  are  complete.  In  Section  B,  we  give  an  illustrative 
example  of  these  processes.  We  also  describe  the  subsequent  semantic  analysis 
necessary  to  complete  the  mapping  process.  The  reader  is  reminded  that  Appen¬ 
dix  C  contains  the  code  for  our  implementation,  written  in  C. 

2.  The  KMS  Data  Structures 

KMS  utilizes  just  two  structures  that  are  defined  in  the  interface.  Natur¬ 
ally,  KMS  requires  access  to  the  Daplex  input  request  structure  discussed  in 
Chapter  II,  the  dpi_dml_tran  (see  Figure  14  again)  structure.  However,  the  only 
two  data  structures  to  be  discussed  here  are  those  unique  to  the  KMS. 

Both  of  these  structures  are  shown  in  Figure  18.  The  first  of  these, 
dap^ms^nfo,  is  a  record  that  contains  information,  not  of  immediate  use,  that 
hzis  been  accumulated  by  the  KMS  during  the  grammar-driven  parse.  This 
record  allows  the  information  to  be  saved  until  a  point  in  the  parsing  process 
where  it  may  be  utilized  in  the  appropriate  portion  of  the  translation  process. 
The  first  four  fields  in  this  record,  point  to  the  same  structure,  ident_list,  the 
second  structure  of  Figure  18,  which  temporarily  holds  a  list  of  names  for  com¬ 
parison  with  the  identifiers,  subtype  indicators,  overlap_sub_node  or 
overlap_ent_node,  and  uniqueness  identifiers,  respectively.  These  names  are  those 
of  attributes  whose  values  are  retrieved  from  the  database.  The  remaining  fields 
of  dap_kms_mfo  contain  pointers  to  Daplex  node  structures  previously  discussed 


struct  dap_kms_^nfo 

{ 

struct  ident^ist  *dki_temp_ptr; 
struct  ident_[ist  *dki_|d_ptr; 

struct  ident^ist  *dki_overfirst_ptr; 

struct  ident_list  *dki_namel_ptr; 

struct  der  _non^ode  dki  _der_non; 
struct  sub_non_node  dki_sub_non; 

struct  ent  _non  _node  dki_ent  _non; 
struct  function_node  dki^unct; 
struct  ent_value  *dki_ev_ptr; 


struct  ident_|ist 

{ 

char  iljname  [ENlength  +  l]; 
struct  ident_l^ist  *il3ext; 

}; 

Figure  18.  The  KMS  Data  Structures. 


in  Chapter  II.  The  remaining  field  of  ident_list  points  to  the  next  name  in  the 
list.  At  the  conclusion  of  the  mapping  process,  and  before  control  is  returned  to 
LIL,  all  data  structures  unique  to  KMS  that  have  been  allocated  during  the  map¬ 
ping  process  are  freed. 

B.  POSSIBLE  FACILITIES  PROVIDED  BY  AN  IMPLEMENTATION 

As  we  reached  this  stage  in  the  implementation,  we  were  confronted  with  two 
problems.  First,  the  deadline  date  for  completion  of  this  project  was  rapidly 
approaching,  and  second,  the  amount  of  code  left  to  produce  was  nearly  equal  to 
the  amount  of  code  that  we  had  provided  to  this  point.  In  addition,  due  to  the 
complexity  of  the  entity-relationship  model,  the  amount  of  code  produced  for  the 
Daplex  implementation  had  met  or  exceeded  the  amount  of  code  for  each  of  the 
implementations  of  DL/I,  SQL,  and  CODASYL  [Refs.  12,  13  and  19].  Accord¬ 
ingly,  a  decision  was  made  to  discontinue  the  implementation  effort  for  this  thesis 
and  leave  the  remainder  for  another  thesis. 


In  the  remainder  of  this  chapter,  we  discuss  those  Daplex  facilities  that  may 
be  provided  by  an  implementation  of  the  entity-relationship  interface.  We  do  not 
discuss  the  Daplex-to-ABDL  translation  in  detail.  Rather,  we  provide  only  an 
overview  of  the  salient  features  of  KMS.  The  interested  reader  is  referred  to 
Goisman  [Ref.  11],  for  a  detailed  discussion  of  the  Daplex-to-ABDL  translation. 
User-issued  requests  may  take  two  forms,  either  Daplex  database  definitions,  or 
Daplex  database  manipulations.  In  the  case  of  database  manipulations,  we  also 
describe  the  semantic  analysis  necessary  to  complete  the  mapping  process. 

1.  Database  Definitions 

When  the  user  informs  the  LIL  that  the  user  wishes  to  create  a  new 
database,  the  job  of  the  KMS  is  to  build  a  entity-relationship  database  schema 
that  corresponds  to  the  database  defin  ition  input  by  the  user.  The  LIL  initially 
allocates  a  new  database  identification  node  (ent_dbid_node  shown  in  Figure  5) 
with  the  name  of  the  new  database,  as  input  by  the  user.  The  LIL  then  sends 
the  KMS  a  complete  database  description  which  takes  the  form  of  a  Daplex  data¬ 
base  declaration  as  follows: 

DATABASE  db_name  IS 
[non_entity_type_declarationsj 
entity_type_declarations 
[entity_type_constraints] 

END  [dbjamej; 

Where: 

db _name:  is  a  valid  identifier  that  is  a  unique 
name  of  the  database  being  declared. 
non_entity_type_declarations:  are  declarations 
of  string  types,  scalar  types,  and 
numeric  constants. 

entity_type_declarations:  are  declarations  of 
entity  types,  their  functions,  and 
generali2ation  hierarchies, 
entity _type_constraints:  define  those  properties 
of  the  declared  entity  type  that  must 
remain  invariant  under  any  operation  on 
values  of  those  types. 


person 


Figure  19.  The  University  Database  Schema 


The  non_entity_type_declarations,  entity_type_declarations,  and 
entity_type_constraints  that  form  a  database  declaration  can  be  intermixed  in 
any  order.  However,  all  types  must  be  declared  (either  completely  or  partially) 
before  the  name  of  the  type  can  appear  in  another  declaration,  Accordingly,  it  is 
apparent  that  for  each  ent_dbid_node,  a  differing  mix  of  ent_node(s), 
gen_sub _node(s),  ent^on _node(s)  and  function _node(s)  is  possible. 

When  LIL  has  forwarded  all  database  definitions  entered  by  the  user,  a 
completed  datab2ise  schema  is  the  result.  A  completed  database  schema  that  uses 
the  University  database  of  Figure  3  is  shown  in  Figure  19.  The  entity- 
relationship  database  schema,  when  completed,  serves  two  purposes.  First,  when 
creating  a  new  database,  it  facilitates  the  construction  of  the  MBDS  template 
and  descriptor  files.  Secondly,  when  processing  requests  against  an  existing  data¬ 
base,  it  allow’s  a  validity  check  of  the  entity,  nonentity,  and  function  names.  It 
also  serves  as  a  source  of  information  for  the  type  checking. 

2.  Database  Manipulations 

When  the  user  wishes  LIL  to  process  requests  against  an  existing  data¬ 
base,  the  first  task  of  the  KMS  is  to  map  the  user’s  Daplex  request  to  an 
equivalent  ABDL  request.  The  only  ABDL  requests  available  are  RETRIEVE, 
RETRIEVE-COMMON,  INSERT,  UPDATE  and  DELETE.  To  these  ABDL 
requests  KMS  must  map  the  Daplex  operators  ASSIGNMENT,  INCLUDE, 
EXCLUDE,  CREATE,  DESTROY,  MOVE  and  PROCEDURE_CALL. 

We  will  not  discuss  PROCEDURE_CALL  as  it  includes  utility  pro¬ 
cedures  such  as  print  and  cancel,  and  these  operations  are  accommodated  by  the 
MLDS  and  ABDL  operators.  In  addition,  we  will  not  discuss  the  RETRIEVE- 
COMMON  statement  of  ABDL.  Further,  the  mappings  will  be  discussed  at  a 
level  of  abstraction  that  does  not  imply  a  specific  coding  implementation,  but 
rather,  a  general  algorithm  that  will  accomplish  the  mapping. 

The  first  mapping  that  we  will  discuss  is  the  CREATE  mapping.  A 
CREATE  statement  is  used  to  create  a  new  database  entity.  The  structure  for 
CREATE  is  shown  in  Figure  20. 

The  function  names  and  values  are  those  function  pairs  that  are  associ¬ 
ated  with  a  specific  entity  type  or  entity  subtype.  The  entity  types  and  entity 


CREATE 


list  of  function  names 
list  of  function  values 
list  of  entity  types  and  entity  subtypes 
to  be  created 
pointer  to  RETRIEVE 
pointer  to  INSERT 
or 

pointer  to  INSERT 


pointer  to  INSERT 

Figure  20.  The  CREATE  Data  Structure. 

subtypes  to  be  used  to  CREATE  a  new  database  entity  are  maintained  in  a  list 
and  the  creation  process  continues  as  long  as  there  are  entity  types  or  entity  sub- 
types  in  the  list. 

In  general,  the  CREATE  algorithm  first  determines  if  the  new  entity 
associated  with  the  function  pair  in  question  is  an  existing  supertype  or  a  termi¬ 
nal  type.  If  so,  then  the  appropriate  super  type/ terminal  type  previously  associ¬ 
ated  with  the  function  pair  is  RETRIEVEd  from  the  database,  and  the  new 
entity  type  or  entity  subtype  is  INSERTed.  Otherwise,  the  new  entity  type  or 
entity  subtype  is  simply  INSERTed  into  the  database. 

The  next  mapping  that  we  will  discuss  is  the  DESTROY  mapping  shown 
in  Figure  21.  The  function  names  and  values  for  the  DESTROY  structure  are 
the  same  as  those  associated  with  the  CREATE  structure,  and  in  fact,  these 
function  pairs  are  the  same  for  all  of  the  subsequent  Daplex  mappings  that  we 
will  discuss.  The  entity  types  and  entity  subtypes  that  are  to  be  DESTROYed 
are  maintained  in  a  list  and  the  destruction  process  continues  as  long  as  there  are 
items  in  the  list  to  be  DESTROYed. 

The  DESTROY  algorithm  only  DELETES  entities,  and  further,  only 
DESTROYS  those  entities  that  are  not  referenced  by  some  database  function. 
Therefore  an  entity  is  RETRIEVEd  and  a  determination  made  as  to  whether  the 
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DESTROY 


list  of  function  names 
list  of  function  values 
list  of  entity  types  and  entity  subtypes 
to  be  destroyed 
pointer  to  RETRIEVE 
pointer  to  DELETE 


pointer  to  DELETE 

Figure  21.  The  DESTROY  Data  Structure. 

entity  is  referenced  by  a  database  function.  If  so,  then  the  DESTROY  operation 
is  aborted.  If  not,  the  entity  is  DELETEd  and  the  process  continues  for  the  next 
entity  to  be  DESTROYed  until  the  list  is  empty. 

The  FOR  EACH  structure  is  shown  in  Figure  22.  The  FOR  EACH 
structure  uses  the  set  of  database  values  as  a  pivot  for  the  iteration  process. 
Each  element  of  the  set  of  database  values  is  paired  with  a  set_expression  for  the 
execution  of  the  loop.  The  setjexpression  values  may  be  entites,  function  names 
or  function  values  and  provide  the  set  of  values  over  which  the  loop  is  iterated. 
Each  RETRIEVE  is  accomplished  on  a  set_expression  value  and  an  element  of 

FOR  EACH 

list  of  sets  of  databeise  values 
set_expression  values 
pointer  to  RETRIEVE 


pointer  to  RETRIEVE 


Figure  22.  The  FOR  EACH  Data  Structure. 


the  set  of  database  values  acts  eis  the  second  arguement  for  the  operation  to  be 
carried  out  by  FOR  EACH.  The  RETRIEVES  continue  until  the  list  of  sets  of 
databzuse  values  is  empty. 

The  ASSIGNMENT  statement  structure  is  shown  in  Figure  23.  The  pur¬ 
pose  of  the  ASSIGNMENT  statement  is  to  assign  entity  values  to  single-valued 
functions. 


ASSIGNMENT 


list  of  function  names 
list  of  function  values 
list  of  entity  types  and  subtypes 
of  each  function 
pointer  to  RETRIEVE 
or 

pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 


pointer  to  RETRIEVE 
REPEAT 

pointer  to  RETRIEVE 


or 


pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 


pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  UPDATE 


pointer  to  UPDATE 

Figure  23.  The  ASSIGNMENT  Data  Structure. 
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purpose  of  the  ASSIGNMENT  statement  is  to  assign  entity  values  to  single¬ 
valued  functions.  To  accomplish  this,  the  ASSIGNMENT  algorithm  searches 
through  the  database  by  RETRIEVing  and  comparing  the  function  to  be 
assigned  to  all  of  the  functions  in  the  database.  In  this  case,,  it  is  assumed  that 
the  function  in  question  exists  and  can  be  found. 

The  search  is  accomplished  by  going  first  to  a  supertype  and  comparing 
the  functions  associated  with  each  of  the  subtypes  until  a  match  is  found.  If  no 
match  is  found,  then  each  subtype  is  treated  as  a  supertype  and  the  search  con¬ 
tinues  downward  through  the  tree  until  the  function  is  found  or  a  terminal  type 
is  reached. 

INCLUDE 

list  of  function  names 
list  of  function  values 
list  of  entity  types  and  subtypes 
of  each  function 
pointer  to  RETRIEVE 
or 

pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 


pointer  to  RETRIEVE 
pointer  to  INSERT 

pointer  to  INSERT 

Figure  24.  The  INCLUDE  Data  Structure. 

Once  the  function  is  found,  the  search  begins  for  all  of  the  function 
values.  This  searching  process  is  similar  to  the  process  for  the  function  lookup 
and  repeats  until  the  desired  value  eissociated  with  the  function  in  question  is 
found.  Once  found,  the  value  is  then  UPDATEd.  The  entire  process  continues 
until  the  list  of  functions  and  values  to  be  assigned  is  empty. 


The  INCLUDE  statement  structure  is  shown  in  Figure  24.  The  purpose 
of  the  INCLUDE  statement  is  to  add  either  a  single  value  or  a  set  of  values  to  a 
set-valued  function.  It  functions  in  a  manner  similar  to  the  ASSIGNMENT 
statement  in  that  the  search  is  accomplished  by  going  first  to  a  supertype  and 
then  comparing  the  functions  associated  with  each  of  the  subtypes  until  a  match 
with  the  desired  function  is  found.  If  no  match  is  found,  then  each  subtype  is 
treated  as  a  supertype  and  the  search  continues  downward  through  the  tree  until 
the  function  is  found  or  a  terminal  type  is  reached.  Once  the  function  is  found, 
the  single  value  or  set  of  values  that  the  user  wishes  to  INCLUDE  is  INSERTed. 

EXCLUDE 

list  of  function  names 
list  of  function  values 
list  of  entity  types  and  subtypes 
of  each  function 
pointer  to  RETRIEVE 
or 

pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 


pointer  to  RETRIEVE 
pointer  to  DELETE 

pointer  to  DELETE 

Figure  25.  The  EXCLUDE  Data  Structure. 

The  EXLUDE  statement  structure  is  almost  identical  to  the  INCLUDE 
statement  structure.  As  can  be  seen  from  Figure  25,  the  only  difference  is  that 
once  the  desired  function  is  found  the  value  is  DELETEd  instead  of  INSERTed. 

The  final  structure  that  we  will  discuss  is  that  of  the  MOVE  statement, 
shown  in  Figure  26.  The  purpose  of  the  MOVE  statement  is  to  change  the  sub- 
types  to  which  an  entity  belongs.  The  MOVE  statement  algorithm  first  performs 


MOVE 


list  of  function  names 
list  of  function  values 
list  of  entity  types  and  subtypes 
to  be  moved 
pointer  to  RETRIEVE 
pointer  to  RETRIEVE 
pointer  to  DELETE 
pointer  to  RETRIEVE 
pointer  to  INSERT 


pointer  to  INSERT 

Figure  26.  The  MOVE  Data  Structure. 

a  RETRIEVE  from  the  database  using  functions  in  entity  valued  expressions  as  a 
search  key,  or  just  using  the  entity  valued  expressions  if  the  associated  functions 
are  not  given.  When  the  entity  valued  expressions  are  located,  the  corresponding 
functions  are  then  searched  for  and  RETRIEVEd.  The  entity  valued  expression 
is  then  DELETEd  from  its  current  location  in  the  database  and  the  new  entity  to 
which  the  entity  valued  expression  is  to  be  eissociated  is  RETRIEVEd.  The 
entity  valued  expression  and  its  2«sociated  function  is  then  INSERTed  into  the 
new  location. 


VI.  CONCLUSION 


In  this  thesis,  we  have  presented  a  partial  specification  and  implementation 
of  a  Daplex  language  interface  .  This  is  one  of  four  language  interfaces  that  the 
multi-lingual  databaise  system  will  support.  When  complete,  the  multi- lingual 
database  system  will  be  able  to  execute  transactions  written  in  four  well-known 
and  important  data  languages,  namely,  SQL,  DL/I,  Daplex,  and  CODASYL.  In 
our  case,  we  support  Daplex  transactions  with  our  language  interface  by  way  of  a 
LIL  and  KMS,  and  have  left  the  production  of  a  Daplex  KC  and  KFS  for  a 
future  thesis.  Related  theses  by  Benson  and  Wentz,  Kloepping  and  Mack,  and 
Emdi  [Refs.  12,  13  and  19j  have  examined  the  specification  and  implementation 
of  the  DL/I,  SQL  and  CODASYL-DML  language  interfaces,  respectively.  All  of 
these  works  are  a  part  of  the  ongoing  research  being  conducted  at  the  Laboratory 
for  Database  Systems  Research,  Naval  Postgraduate  School,  Monterey, 
California. 

The  need  to  provide  an  alternative  to  the  development  of  separate 
stand-alone  databaise  systems  for  specific  data  language  models  has  been  the 
motivation  for  this  research.  In  this  regard,  we  have  first  demonstrated  the  feasi¬ 
bility  of  a  multi-lingual  database  system  (MLDS)  by  showing  how  a  software 
Daplex  language  interface  can  be  constructed. 

A  major  goal  has  been  to  design  a  Daplex-to-MBDS  interface  without 
requiring  any  change  be  made  to  MBDS  or  ABDL.  Our  partial  implementation 
may  be  completely  resident  on  a  host  computer  or  the  controller.  All  Daplex 
transactions  will  be  performed  in  the  Daplex  interface.  MBDS  continues  to 
receive  and  process  transactions  written  in  the  unaltered  syntax  of  .\BDL.  In 
addition,  our  implementation  has  not  required  any  change  to  the  syntax  of 
Daplex.  The  interface  will  be  completely  transparent  to  the  Daplex  user  as  well 
as  to  the  MBDL. 

In  retrospect,  our  level-by-level,  top-down  approach  to  the  design  of  the 
interface  has  been  a  good  choice.  This  implementation  methodology  has  been  the 


most  familiar  to  us  and  proved  to  be  relatively  efficient  in  time.  In  addition, 
this  approach  permits  follow-on  programmers  to  easily  maintain  and  modify 
(when  necessary)  the  code.  Subsequently,  they  will  know  exactly  w'here  we 
have  stopped  and  where  they  should  begin  because  we  have  included  many  of 
the  lower-level  stubs.  Hence,  it  is  an  easy  task  to  fill  in  these  stubs  with  code. 

To  our  great  disappointment  we  have  not  been  able  to  complete  the  imple¬ 
mentation.  The  primary  reason  for  our  failure  has  been  the  complexity  of  the 
entity-relationship  model  and  the  Daplex  language.  This  complexity  has  been 
directly  responsible  for  our  underestimation  of  the  amount  of  code  necessary  for 
the  Daplex  interface  implementation.  To  date,  we  have  produced  an  amount  of 
code  at  least  equal  to  each  of  the  other  complete  implementations,  and  are  faced 
with  producing  an  equal  amount  in  order  to  complete  the  implementation. 

However,  we  have  shown  that  a  Daplex  interface  can  be  implemented  as  part 
of  a  MLDS.  We  have  provided  a  partial  software  structure  to  facilitate  this 
interface,  and  we  have  developed  actual  code  for  implementation.  The  next  step 
is  to  complete  the  development  of  the  Daplex  interface.  When  complete,  this 
interface  can  be  integrated  with  the  other  implementations  and  tested  as  a  whole 
to  determine  how  efficient,  effective,  and  responsive  it  can  be  to  a  users’  needs. 
The  results  may  be  the  impetus  for  a  new  direction  in  database  system  research 
and  development. 


APPENDIX  A 


DAPLEX  DATA  STRUCTURES 

/*  this  is  a  list  of  the  data  structures  for  the  daplex  project  */ 


union  dbid  _node 

/*  Union  definition  for  the  database.  There  is  a  common  */ 
/*  database  node  definition  that  spans  the  four  types  of  */ 
/*  language  interfaces.  Abbr:  rel(ational),  hie(archical),*/ 
/*  net{work),  and  entity-relationship.  */ 

{ 

struct  rel_dbid_node  *dn_rel; 
struct  hie_dbid_node  *dn  _hie; 

struct  net_dbid  _node  *dn_net; 

struct  ent_dbid_node  *dn_dap; 

}; 


struct  ent_dbid  jode 

/*  structure  def  for  each  entity-relationship  dbid  node  */ 

{ 


char 

edn  _nameiDBNLength  +  l|; 

struct 

ent jnon_node 

*edn  _nonentity; 

int 

edn  jum  jionent;  /*  number  of  nonentity  types  */ 

struct 

ent^ode 

*edn_entity; 

int 

edn_num_ent; 

/*  number  of  entity  types  */ 

struct 

gen_sub_node 

*edn_subptr; 

int 

edn_num_gen; 

/*  number  of  gen__subtypes  */ 

struct 

sub_non_node 

*edn  nonsubptr; 

int 

edn_num_nonsub;  /*  number  of  nonentity  subtypes  */ 

struct 

der_non_node 

*edn_nonderptr; 

int 

edn_num_der; 

/*  nmbr  or  nonentity  derived  types 

struct 

ent  dbid  node 

*edn_next_clb; 

struct  ent  jiode 

/*  structure  definition  for  each  entity  node  */ 

{ 

char  en_namejENLength  -I-  l]; 

int  en_num_funct;  /*  number  of  assoc,  functions  */ 
int  en_terminal;  /*  if  true  (=1)  it  is  a  terminal  type  */ 
struct  function_node  *cn_ftnptr, 
struct  ent  node  *en  next  ent: 


struct  gen_sub_node 

/*  structure  def  for  each  generalization  (supertype/subtype)  node  */ 

{ 

char  gsn_name[ENLength  +  Ij; 

int  gsn _num_funct;  /*  number  of  assoc,  functions*/ 

int  gsn_terminal;  /*  if  true  (=1)  it  is  a  terminal  type  */ 

struct  overlap_ent_node  *gsn_entptr;  /*  ptr  to  entity  supertype  */ 

int  gsn_num_ent;  /*  number  of  entity  supertypes  */ 

struct  function  _node  *gsn_ftnptr; 

struct  overlap_sub_node  *gsn_subptr;  /*  ptr  to  subtype  supertype  */ 
int  gsn_num_sub;  /*  number  of  subtype  supertypes  */ 
struct  gen_sub_node  *gsn_next_genptr; 

}; 


struct  ent _non_node 

/*  structure  def  for  each  base-type  nonentity  node  */ 

{ 

char  enn  jamejENLength  -I-  l]; 

char  enn_type;  /*  either  i(nteger),  s(tring), 

f(loat),  e(numeration),  or  b(oolean)  */ 
int  enn_totalJength;  /*  max  length  of  base-type  value  */ 
int  enn_range;  /*  true  or  false  depending  on  whether 
there  is  a  range.  If  a  range  exists, 
there  must  be  two  entries  into  ent_yalue  */ 
int  enn_num_yalues;  /*  number  of  actual  values  */ 
struct  ent_yalue  /•enn_yalue;  /*  actual  value  of  base-type  */ 
int  enn_constant;  /*  boolean  to  refelect  constant  value  */ 
struct  ent  jon _node  *enn_next_node; 

}; 


•  w- .  •  . 


-  J 


struct  sub_non_node 

/*  structure  def  for  each  subtype  nonentity  node  */ 

{ 

char  snn_jiame|ENLength  +  ij; 

char  snn_type;  /*  either  i(nteger),  s{tring), 

f(loat),  e(numeration),  or  b(oolean)  */ 
int  snn_totaMength;  /*  max  length  of  subtype  value  */ 
int  snn_range;  /*  true  or  false  depending  on  whether 
there  is  a  range.  If  a  range  exists, 
there  must  be  two  entries  into  ent_yalue  */ 
int  snnjtum_yalues;  /*  number  of  actual  values  */ 
struct  ent_yalue  *snn_yalue;  /*  actual  value  of  subtype  */ 
struct  sub_non_node  *snn_next  jode; 

}; 


P 
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struct  der_non_node 

/*  structure  def  for  each  derived  type  nonentity  node  */ 

{ 

char  dnn_naine|ENLength  +  l]; 

char  dnn_type;  /*  either  i(nteger),  9(tring), 

f(Ioat),  e(nuineration),  or  b(oolean)  */ 
int  dnn_total_length;  /*  max  length  of  derived  type  value  * / 
int  dnn_range;  /*  true  or  false  depending  on  whether 
there  is  a  range.  If  a  range  exists, 
there  must  be  two  entries  into  ent_value  *  j 
int  dnn_num_yalues;  /*  number  of  actual  values  */ 
struct  ent_yalue  *dnn_yalue;  /*  actual  value  of  derived  type  */ 
struct  der_non _node  *dnn _next_node; 

}; 

struct  function  jode 

/*  structure  definition  for  each  function  type  declaration  */ 

{ 

char  fn  jiamejENLength+l); 

char  fn_type;  /*  either  f(loat),  i(nteger),  s(tring), 

b(oolean),  or  e(numeration)  */ 
int  fn_range;  /*  Boolean  if  range  of  values  */ 

int  fn_total_jength;  /*  max  length  */ 
int  fn_num_yalue;  /*  number  of  actual  values  */ 
struct  ent_yalue  *fn_yalue;  /*  actual  value  */ 
struct  ent_jiode  *fn_entptr;  /*  ptr  to  entity  type  */ 
struct  gen_sub_node  *fn_subptr;  /*  ptr  to  entity  subtype  */ 
struct  ent_non  jiode  *fn_nonentptr;  /*  ptr  to  nonentity  type  */ 
struct  sub_non_node  ‘fnjionsubptr;  /*  ptr  to  nonentity  subtype  */ 
struct  derjionjiode  *fn jionderptr;  /*  ptr  to  nonentity  dertype  */ 
int  fn_entnull;  /*  initialized  false  set  true  for  no  value  */ 
int  fn_unique;  /*  init  false  -  unique  if  true  */ 
struct  function_node  *fn_next_fntptr; 

}; 

struct  user_info 

/*  This  structure  is  used  to  maintain  information  on  all  of  the  */ 

/*  current  users  of  the  particulsir  interface.  The  interface  type  */ 

/*  is  determined  by  the  li_info  structure.  */ 

{ 

char  ui_uid|UIDLength  +  Ij;  /*  The  user  id  */ 

union  li_info  ui_li_type;  /*  li  is  for  language  interface  */ 

struct  u8er_info  *ui_next_user; 


union  li_i^nfo 

/*  This  union  is  used  to  choose  a  particular  data  structure.  */ 

/*  The  data  structure  chosen  is  interface  dependent,  i.e.,  */ 

/*  li_3ql  is  for  the  relational  interface,  li _dli  is  for  the  */ 

/*  hierarchical  interface  and  li_dml  is  for  the  network  int.  */ 

/*  and  Ii_dap  is  for  the  entity  relationship  interface.  */ 

{ 

struct  sql_info  li  _8ql; 

struct  dli_i^nfo  lijdli; 

struct  dml_info  li_dinl; 
struct  dap_info  li_dap; 

}; 

struct  dap^info 

/*  The  structure  for  info  about  the  daplex  request  for  a  user  */ 

{ 

struct  curr_db_info  dpi _curr_db;  /*  The  current  user  */ 

struct  rile_info  dpi_rile;  /*  The  dap  files  of  request  * / 

struct  tran_info  dpi_dml_tran;  /*  The  dml  transactions  */ 

struct  ddl_info  *dpi_ddl_files;  /*  The  abdl  ddl  files  * f 

int  dap_operation;  /*  The  operation  to  be  performed  */ 

int  dap  _answer; 

int  dap_error; 

int  dap_bufr_count; 

union  kmsjnfo  dpi  _kms_data; 

union  kfs  jnfo  dpijkfsjdata; 

union  kc  info  dpi  kc  data; 


APPENDIX  B 


THE  STORAGE  AND  RETRIEVAL  MODULES 


A.  STORAGE 


/*  this  file  is  savefree.c  */ 


^include  <stdio.h> 

^include  "flags. deP' 

^include  "licommdata.deP' 

^include  "struct. def 
^include  "dap. ext" 

strfr_dap_db_list  0 

{ 

/*  begin  strfr_dap_db_list  */ 

struct  ent_dbid _node  *db_ptr;  /*  ptr  to  the  database  list  */ 

struct  ent_non  jode  *non_ent_ptr;  /*  ptr  to  the  nonentity  node  */ 
struct  ent_yalue*entval_ptr;  /*  ptr  to  the  entity  value  node  */ 
struct  sub _non^ode  *subnon_ptr;  /*  ptr  to  nonent  subtype  node  */ 

struct  der_non_node  ‘demon jptr;  /*  ptr  to  derived  subtype  node  */ 

struct  ent_node  *ent_node_ptr;  /*  ptr  to  the  entity  node  */ 

struct  gen^ub_node  *gen_ptr;  /*  ptr  to  the  gen  subtype  node  */ 
struct  overlap_ent_node  *overlapent_ptr;  /*  ptr  to  the  entity  subtype  ‘/ 
struct  overlap_sub  jode  *overlapsub_ptr;  /‘  ptr  to  the  term  subtype  */ 
struct  function_node  *func_ptr;  /*  ptr  to  the  function  node  */ 

FILE  *dap_fid; 

char  temp _strlNUMDIGIT  +  1); 


/*  this  function  saves  the  entity/functional  schema  */ 
/*  back  to  a  file  and  frees  the  list  it  occupied  */ 


#iflef  EnExFlag 

printf("Enter  strfr_dap_db_Jist"); 

#endif 


if  ((dapjid  =  fopen  (DAPDBSFname,  "w"))  ==  NULL) 
{  /♦  begin  if  NULL  */ 

printf("Unable  to  open  %s",  DAPDBSFname); 
ring_the_bell(); 


#iflef  EnExFlag 

printf("Exitl  strfr_dap_db_list"); 

#endif 

return; 

}  /•  end  if  NULL  ‘/ 
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db_ptr  =  dbs_dap_head_ptr.dn_dttp; 
while  (db_ptr  !=  NULL) 

{  /*  the  database  is  stored  to  the  file  here  */ 

wr_ent_dbid_node(dap^d,db_ptr); 
non_ent_ptr  =  db_ptr  ->  edn_nonentity; 

while  (non_ent_ptr  !=  NULL) 

{  /*  begin  while  non_ent_ptr  !=  NULL  */ 

proc_ent_non_node(dap_fid,  non_ent_ptr); 
non_ent_j)tr  =  non_ent_ptr  ->  enn _next_node; 

}  /*  end  while  non_ent_ptr  !=  NULL  */ 

ent  jode_ptr  =  db_ptr  ->  edn_entity; 
nunn_to_str(db_ptr  ->  edn_nuni_ent,  temp_str); 
writestr(dap_fid,  temp_str); 

while  (ent  jode_ptr  !=  NULL) 

{  /•  begin  while  ent_node_ptr  !=  NULL)  */ 

wr _ent^ode(dap_fid,  ent_node_ptr); 

ent _node_ptr  =  ent_node_ptr  •>  en_next_ent; 

}  /•  end  while  ent _node_ptr  !=  NULL  */ 

gen_ptr  =  db_ptr  ->  edn_subptr, 
num  Jo_str(db_ptr  ->  edn  jium  jen,  temp_str); 
writestr(dap_fid,  temp_str); 

while  (gen_ptr  !=  NULL) 

{  /*  begin  while  gen_ptr  !=  NULL  */ 

wr_gen_sub_node(dap_fid,gen  jitr); 
gen_ptr  =  gen_ptr  ->  gsn _next_genptr; 

}  /*  end  while  gen_ptr  !=  NULL  */ 

gen_ptr  =  db_ptr  ->  edn_subptr; 

while(gen_ptr  !=  NULL) 

{  /*  begin  while  gen_ptr  !=  NULL  */ 

nuni_to_str(gen_ptr ->  gsn_num_ent,  temp_str); 
writestr  (dap_fid,  temp_jtr); 
overlapent_ptr  =  gen  jptr  ->  gsn_entptr; 

while(  overlapent_ptr  !=  NULL) 

{  j*  begin  while  overlapent_ptr  !=  NULL  */ 

writestr(dap_fid,  overlapent_ptr  ->  oen_name  ->  en_name 
overlapent_ptr  =  overlapent^ptr  ->  oen_next_name; 


}  /*  end  while  overlapent  ptr  !=  NULL  */ 


num  Jto_str(gen_ptr  ->  gsn  jum _sub,  temp_str); 
writestr(dap_fid,  temp_str); 
overlapsub_ptr  =  gen_ptr  ->  gsn^ubptr; 

while  (overlapsub_ptr  !=  NULL) 

{  /*  begin  while  overlapsub_ptr  !=  NULL  */ 

writeatr(dap_fid,  overlapsub_ptr  ->  osn_name  ->  gsn_name); 
overlap8ub_ptr  =  overlapsub_ptr  ->osn _next _name; 

}  /*  end  while  overlapsub_ptr  !=  NULL  */ 

genjtr  =  genjptr  ->  gsn_nextjgenptr; 

}  /*  end  while  gen_ptr  !=  NULL  */ 

/*  Process  the  sub  non  nodes  *  j 

subnon_ptr  =  db_ptr  ->  edn _nonsubptr; 

num_to _str  (db_ptr ->  ednjum _nonsub,  tenip_str); 

writestr  {dap_fid,  temp_str); 

while  (subnon_ptr  !=  NULL) 

{  /•  begin  while  subnonjptr  <>  NULL  */ 

proc_sub jionjode  (dap_fid,subnon_ptr); 
subnon_ptr  =  subnon_ptr  ->  snn _next _node; 

}  /*  end  while  subnon_ptr  <>  NULL  */ 

/*  Process  the  derived  nodes  */ 

dernon_ptr  =  db_ptr  ->  edn_nonderptr; 
num_to_str(db_ptr  ->  edn_num_der,  temp_str); 
writestr(dap _fid,  temp_str); 

while  (dernon_ptr  !=  NULL) 

{  /*  begin  while  dernon_ptr  <>  NULL  */ 

proc_der_non_node  (dap_fid,dernon_ptr); 
dernon_ptr  =  dernon_ptr  ->  dnn_next_node; 

}  /*  end  while  dernon_ptr  <>  NULL  */ 

/*  Process  the  Ent  function  nodes  */ 

ent_node_ptr  =  db_ptr  ->  edn_entity; 

while  (ent^ode_ptr  !=  NULL) 

{  /*  begin  while  ent_node_ptr  !=  NULL  */ 

wr _all_ent^ode(dap_fid,  ent_node_ptr); 
ent_node_ptr  =  ent_node_ptr  •>  en_next_ent; 

}  /*  end  while  ent _node_ptr  f=  NULL  */ 
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gen  j>tr  =  dbj)tr  ->  edn_subptr; 


while  (gen  j)tr  !=  NULL) 

{  /*  begin  while  gen_ptr  !=  NULL  */ 

func_ptr  =  genjptr  ->  gsn_ftnptr; 

while  (func_ptr  !=  NULL) 

{  /*  begin  while  func_ptr  !=  NULL  */ 

proc_function_node(dap^d,func_ptr); 
gen_ptr->gsn^tnptr  =  func_ptr->fn_next_fntpt 
freejTunction  jode(func_ptr); 
func_ptr  =  gen_ptr  ->  gsn_ftnptr; 

}  /*  end  while  func_ptr  !=  NULL  * / 

gen_ptr  =  gen_ptr  ->  gsnj;iext_genptr; 

}  /*  end  while  gen_ptr  !=  NULL  */ 

db_ptr  =  db_ptr  ->  edn_next_db; 

}  /*  end  while  db_ptr  !=  NULL  */ 

putc(’$’,  dap_fid); 
putcj”,  dapjTid); 


#ifief  EnExFlag 

printf("Exit  strfr_dap_db_list"); 

#endif 

}  /*  end  strfr_dap_dbj^ist  */ 

wr_ent_dbid  jode{  fTid,  db_ptr) 

FILE  ‘Rid; 

struct  ent_dbid_node  *db_ptr; 

{ 

char  teinp_str[NUMDIGIT  +  ij; 

/*  this  function  writes  the  database  */ 
/*  structure’s  contents  to  the  save  file  */ 

#iflef  EnExFlag 

printf("Enter  wr_ent_dbid  jode"); 

#endif 


writestr(fnd,  db_ptr  ->  edn_nanie); 
nuni_to_str(db_ptr  ->  edn_nuni_nonent,  temp_str); 
writestr(fnd,  temp_str); 

#LBef  EnExFlag 

printf("Exit  wr_ent_dbid _node"); 

#endif 

}  /*  end  wr_ent_dbid  jode  */ 


proc_ent_non^ode(fid,  non_ptr) 

FILE  ‘fid; 

struct  ent_non  _node  *non_ptr; 

{  /*  begin  proc_ent_non_node  */ 

struct  ent_va.lue  *val_ptr; 
char  temp_str[NUMDIGlT  +  Ij; 


#iflef  EnExFlag 

printf("Enter  proc_ent_non_node"); 

#endif 


writestr(fid,  non_ptr  ->  enn^ame); 
putc(non_ptr  ->  enn_type,  fid); 
putc(”,  fid); 

num_to_str(non_ptr  ->  enn_total_jength,  temp_str); 
writestr(fid,  temp_str); 

num_to_str(non_ptr  ->  ennj;ange,  temp _str); 
writestr(fid,  temp_str); 

num_to_str(non  j)tr  ->  eiin_constant,  temp_str); 
writestr(fid,  temp^str); 

num_to _str(non_ptr  ->  enn_num_values,  temp_str); 

writestr(fid,  temp_str); 

val_ptr  =  non_ptr  ->  enn_value; 

while  (val_ptr  !=  NULL) 

{  /*  begin  while  val_ptr  <>  NULL  */ 

writestr(fid,val_ptr  ->  ev_yalue); 
val_ptr  =  val_ptr  ->  ev_next_yalue; 

}  /*  end  while  valjptr  <>  NULL  */ 

^iflef  EnExFlag 

printf("Exit  proc_ent^on _node"); 

#endif 


}  /*  end  proc_ent _nonjiode  */ 

wr_ent_node(fid,ent_ptr) 

FILE  ♦fid; 

struct  ent_node  ‘entjtr; 

{  /♦  begin  wr_ent _node  ♦/ 

char  temp_str[NUMDIGIT  +  l]; 

#iflef  EnExFlag 

printf("Enter  wr_ent_node"); 

^endif 


writestr(fid,  entjptr  ->  en_name); 
num_to_str(ent_ptr  ->  en_num_funct,  temp_str); 
writestr(fid,  temp_str); 

num_to_8tr(ent_ptr  ->  en_terminal,  temp_str); 
writestr(fid,  temp_str); 


#iflef  EnExFlag 


#endif 


printf("Exit  wr_ent  jode"); 
}  /*  end  wr_ent  jode  */ 


wr_gen_sub_node(fid,gs  _ptr) 

FILE  ‘fid; 

struct  gcn_sub _node  *gs _ptr; 

(  /*  begin  wr_gen  jub  jode  */ 
char  teinp_str[NUMDlGIT  +  l); 

#iflef  EnExFlag 

printf("Enter  wr_gen _sub _node"); 

#endif 

writestr(fid,gs  j>tr  ->  gsn  jame); 

num  Jo_str(gs_ptr  ->  gsn _nufn  Junct,  temp^tr); 

writestr(fid,  teinp_str); 

nuni_to _str(gs  j>tr  ->  gsn_terminal,  temp^tr); 
writestr(fid,  temp_str); 


#iflef  EnExFlag 

printf("Exit  wr_gen_sub_node"); 

^endif 

}  /*  end  wrjgen_sub _node  */ 
proc_sub _non _node{fid,  sub_ptr) 

FILE  ‘fid; 

struct  sub  _non  _node  *sub  __ptr; 

(  /*  begin  proc_sub_non  jode  */ 

FILE  *fid; 

struct  ent_value  *val_ptr, 

char  teinp^tr[NUMDIGIT  +  ij; 

#iflef  EnExFlag 

printf("Enter  proc_sub  jon  jode"); 

#endif 

writestr(fid,  sub_ptr  ->  snn _namc); 
putc  (sub_ptr  ->  snn_type,  fid); 
putc(”,  fid); 

num_to_str(sub_ptr  ->  snn_total_Iength,  temp_strj, 
writestr(fid,temp_str); 

num  jo_str(sub_ptr  ->  snn_range,  temp_str); 
writestr(fid,  teinp_str); 

val _ptr  =  sub_ptr  ->  snn_value; 

while  (val_ptr  !=  NULL) 

{  /*  begin  while  val _ptr  <>  NULL  */ 

write8tr(fid,  val_ptr  ->  ev_yalue  ); 
val_ptr  =  val_ptr  ->  ev  jext_yalue; 

}  /*  end  while  val_ptr  <>  NULL  */ 
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#ifler  EnExFIag 

printf("Exit  proc_sub_non_node"); 

#endif 

}  /*  end  proc_sub_non _node  * / 

prc>c_der_non_node(fid,der_ptr) 

FILE  *fid; 

struct  der_non_nt)de  *der_ptr; 

{  /*  begin  proc_der_non_node  */ 

struct  ent_yalue  *val_ptr; 

char  temp_strjNUMDlGIT  +  1|; 

#iflef  EnExFIag 

printf("Enter  proc_der^on^ode"); 

^endif 

writestr(fid,  der_ptr  ->  dnn_name); 
putc  (der_ptr  ->  dnn_type,  fid); 
putc(”,  fid); 

num_to_str(der  j)tr  ->  dnn_total_length,  teinp_str); 
writestr(fid,  temp_str); 

num_to_str(der_ptr  ->  dnn^ange,  temp  jtr); 

writestr(fid,  temp_str); 

val_ptr  =  der_ptr->  dnn_yalue; 

while  (val_ptr  !=  NULL) 

{  /*  begin  while  val_ptr  <>  NULL  * j 

writestr(fid,  val_ptr  ->  ev_yalue); 
val_ptr  =  valjitr  ->  ev_next_yalue; 

}  /*  end  while  val_ptr  <>  NULL  */ 

#iflef  EnExFIag 

printf("Exit  proc_der_non_node"); 

#endif 

}  j*  end  proc_der_non_node  */ 

wr  _all_ent  jode(fid,ent_ptr) 

FILE  *fid; 

struct  ent_node  ‘entjptr; 

{  /*  begin  wr _all_ent_node  */ 

struct  function_node  *funct_ptr; 
char  temp_str(NUMDIGIT  +  l); 

#ifief  EnExFIag 

printf("Enter  wr_aU_ent  jode"); 

#endif 

funct_ptr  =  ent_ptr  ->  enjftnptr; 

while  (funct_ptr  !=  NULL) 

{  /*  begin  while  funct_ptr  <>  NULL  */ 

proc^unction_node(fid,funct  ptr); 


ent_ptr  ->  en_ftnptr  =  funct_ptr  ->  fn  jiext_fntptr; 

free_functioii_node(fmict_ptr); 

funct_ptr  =  ent_ptr  ->  en_ftnptr; 

}  /*  end  while  funct_ptr  <>  NULL  */ 

#iflef  EnExFlag 

printf("Exit  wr _&ll_enl_node '); 

#endif 

}  /*  end  wr _all_ent_node  */ 


proc_function_node(rid,fptr) 

FILE  ‘fid; 

struct  functionjode  *fptr; 

{  /*  begin  proc_function_node  */ 

struct  ent_yalue  *val_ptr; 

struct  ent_node*eptr; 
struct  gen _sub_node  *gsptr; 

struct  ent_non_node  *enptr; 

struct  sub_non _node  *snptr; 

struct  der _non_node  *dnptr; 

char  temp_strjNUMDIGIT  +  1|; 

#iflef  EnExFIag 

printf("Enter  proc_function_node”); 

#endif 

writestr(fid,  fptr  ->  fnjiame); 
putc(fptr  ->  fn_type,  fid); 
putcj”,  fid); 

num_to_str(fptr  ->  fnj;ange,  tenip_str); 
writestr(fid,  temp _str); 

num_to_str(fptr ->  fn_total_length,  temp_str); 
writestr(fid,  temp_str), 

num_to_str(fptr  ->  fnjium_yalue,  temp_str); 
writestr(fid,  temp_str); 
val_ptr  =  fptr  ->  fn_yalue; 

while  (val_ptr  !=  NULL) 

{  j*  begin  while  val_ptr  <>  NULL  */ 

writestr  (  fid,  val_ptr  ->  ev_value); 
val_ptr  =  val_ptr  ->  ev _next_yalue; 

}  /*  end  while  val_ptr  <>  NULL  */ 

eptr  =  fptr  ->  fn_entptr; 

if(eptr  !=  NULL) 
write8tr(fid,  eptr  ->  en_name); 
else 

writestr(fid,  "“"); 


gsptr  =  fptr  ->  fn_5ubptr; 


if(gsptr  !=  NULL) 

writestr(fid,  gsptr  ->  gsn_name); 

else 

writestr(rid, 

enptr  =  fptr  ->  fn_nonentptr; 

if(enptr  !=  NULL) 
writestr(fid,  enptr  ->  enn^ame); 
else 

writestr(rid,  "*"); 

snptr  =  fptr  ->  fn_nonsubptr; 

if(snptr  !=  NULL) 
wr)testr(fid,  snptr  ->  snn _naine); 
else 

writestr(fid,  "“"); 

dnptr  =  fptr  ->  fn_nonderptr; 

if(dnptr  !=  NULL) 
writestr(fid,  dnptr  ->  dnn _name); 
else 

writestr(fid,  "'"); 

num_to_str(fptr  ->  fn_entnull,  temp_str); 
writestr(fid,  temp_str); 
num_to^tr{fptr  ->  fn_unique,  temp_str); 
writestr(fid,  temp_str); 


#iflef  EnExFlag 

printf("Exit  proc_function _node"); 

#endif 

}  /*  end  proc_function  jode  */ 

free^unction_node(f«nc_ptr) 

struct  functionjiode  *func_ptr; 
{  /*  begin  free_function_node  */ 

#iflef  EnExFlag 

printf("Enter  free^functionjiode"); 

#endif 

strcpy(func_ptr  ->  fn _name,  "  "); 
func_ptr  ->  fn_type  =  ’ 
func_ptr  ->  fn^ange  =  0; 
func_ptr  ->  fn_total_length  =  0; 
func_ptr  ->  fn_nuni_value  =  0; 
func_ptr  ->  fii_yalue  =  NULL; 
func_ptr  ->  fn_entptr  =  NULL; 
funcj>tr  ->  fn_subptr  =  NULL; 
func_ptr  ->  fnjionentptr  =  NULL; 
func  ptr  ->  fn_noRsubptr  =  NULL; 


funcjptr->  fn_nonderptr  =  NULL; 
func_ptr  ->  fn_eiitnull  =  0; 
func_ptr  ->  fn_unique  =  0; 
func_ptr  ->  fn  jext_fntptr  =  NULL; 

EnExFlag 

printf("Exit  free_function_node"); 

#endif 

}  /*  end  free_function _node  */ 


B.  RETRIEVAL 


/*  This  file  is  makelist.c  */ 

^include  <stdio.h> 

^include  "flags. def 
^include  "licommdata.der' 

#include  "struct. def 
^include  "dap. ext" 

creat_dap_db_list  ( ) 

{ 

struct  ent _dbid_node  *iiew_db_ptr,  *db_ptr;  /*  ptr  to  the  enty-relationp  node  */ 

struct  ent  j;ion_node  *new_non_ent_ptr,  *non_ent_ptr;  /*  ptr  to  nonenty  node  */ 

struct  ent_yalue  *new_entval_ptr,  *entval_ptr;  /*  ptr  to  the  enty  value  node  */ 

struct  sub_non_node  *new_subnon_ptr,  *3ubnon_ptr;  /*ptr  to  subjionenty  node  * / 

struct  ent _node  *new _ent _nodejptr,  *ent _node _ptr;  /*  ptr  to  the  entity  node  */ 

struct  gen_sub _node  *new_gen_ptr,  *gen_ptr;  /*  ptr  to  gen  super, subtype  node  */ 

struct  overlap _ent_node  *new_overIapent jptr,  *overlapent jptr; 

struct  overlap _sub_node  *new_overlapsub_ptr,  *overlapsub_ptr; 

struct  function_node  *ne'w_func_ptr,  *func_ptr;  /*  ptr  to  the  function  node  */ 

struct  der _non  jode  *new_dernon_ptr,  ‘demon  j>tr;  /*  ptr  to  nonent  der  node  */ 

int  ed_count,  ent_count,  funct_count,  nuin_yal;  /*  counters  */ 

int  gen_3ub_count,  super_count,  sub_super_count;  /*  counters  */ 

int  non^ub_count,  non_der_count,  enum_count;  /*  counters  */ 

int  done_nag,  first_db,  first_nonnode;  /*  booleans  */ 

int  first_enum,  first_node,  first_func;  /*  booleans  */ 

int  first_value,  rirst_gen_sub,  first_super;  /*  booleans  */ 

int  first _sub _super,  first _non_sub;  /*  booleans  */ 

int  flrst_non_der;  /*  boolean  */ 

struct  ent_dbid _node  *rd_ent_dbid _node(); 

struct  ent_non_node  *rd_ent_non_node(); 

struct  ent_yalue  *rd_ent_yalue(); 

struct  sub_jion_node  *rd_sub jon_node(); 

struct  entjode  *rd_ent_node(); 

struct  gen _sub_node  *rd_gen _sub _node(); 

struct  overlap_ent_node  *rd_overlap_ent_node(); 

struct  overIap_siib_node  *rd_overlap_sub_node(); 

struct  function_node  *rd_function_node(); 

struct  der_non_node  *rd_der_non_node(); 

FILE  *dap_fid; 

char  temp_str|NUMDlGIT  +  l|; 


/*  This  function  retrieves  and  recreates  the  schema  from  the  stored  file  */ 


#iflef  EnExFlag 

printf  ("Enter  create_dap_db_list"); 

#endif 

if  {  (dapjid  =  fopen(  DAPDBSFname,  "r")  )  ==  NULL) 

{ 

printf  ("Unable  to  open  file  %s",  DAPDBSFname); 
ring_the_bell(); 

#iflef  EnExFlag 

printf  ("Exitl  creat_dap _db_list"); 

#endif 

return; 

} 

done_flag  =  FALSE; 

first  jdb  =  TRUE; 

while  (  donejlag  !=  TRUE  ) 

{ 

/*  the  schema  nodes  are  allocated  and  filled  here  */ 
new_db_ptr  =  rd_ent_dbid^ode(  dap_fid,  &.done_nag); 
if  (  done _nag  !=  TRUE  ) 

{ 

if  (  first _db  ==  TRUE  ) 

/*  special  case  of  accessing  the  first  entity  relationship  */ 
dbs_dap  _head_ptr.dn_dap  =  new_db_ptr; 
db_ptr  =  new_db_ptr; 
first_db  =  TRUE; 

} 

else 

{ 

db_ptr->edn  jext_db  =  new_db_ptr; 
db_ptr  =  new_db_ptr; 

} 

first  _nonnode  =  TRUE; 

ed_count  =  db_ptr->edn_num_nonent; 

while  (  ed _count  !=  0  ) 

{ 

/*  the  nonentity  nodes  are  allocated  and  filled  here  */ 
new  jon_ent_ptr  =  rd_ent_non_node(dBp_fid); 
if  (  first_nonnode  ==  TRUE  ) 

{ 

I*  special  case  for  first  nonentity  */ 
db_ptr->edn_nonentity  =  new_non_ent_ptr; 
non_ent_ptr  =  new  _non_ent_ptr; 
first  nonnode  =  FALSE; 


non_ent_ptr->enn_next_node  =  new_non_ent_ptr; 
non_ent_ptr  =  new_non_ent_ptr, 

} 

first_enuin  =  TRUE; 

enum_count  =  non_ent_ptr->enn  juin_yalues; 
while  (  enum_count  !=  0  ) 

{ 

/*  the  actual  value  nodes  are  allocated  and  filled  here  *  j 
new_entval_ptr  =  rd_ent_yalue(dap_fid, 

non_ent_ptr->enn_totaMength); 
if  (  rirst_enuin  ==  TRUE  ) 

{ 

j*  special  case  of  first  actual  value  */ 
non  _ent_ptr->enn_yalue  =  new  _entval_ptr; 
entval_ptr  =  new_entval_ptr; 
first_enum  =  FALSE; 

} 

else 

{ 

entval_ptr->ev  jext_yalue  =  new_entval_ptr; 
entval_ptr  =  new_entval_ptr; 

} 

— enumjcount; 

}  /*  end  value  loop  */ 

— ed_count; 

}  /*  end  base  type  nonentity  loop  */ 

first_node  =  TRUE; 
readstr(dap_fid,temp_8tr); 

db_ptr->edn  _nufn_ent  =  str_to  _nuni(tenip_str); 
ent_count  =  db_ptr->edn  _num_ent; 
while  (  ent_count  !=  0  ) 

{ 

j*  the  entity  nodes  are  allocated  and  filled  in  here  */ 
new_ent_node_ptr  =  rd_ent_node(dap_fid); 
if  (first_node  ==  TRUE  ) 

{ 

/*  special  case  of  first  entity  node  */ 
db_ptr->edn_entity  =  new_ent  _node_ptr; 
ent_node_ptr  =  new_ent_nodejptr; 
first_jiode  =  FALSE; 

} 

else 

{ 

ent_node_ptr->en_next_ent  =  new_ent_node_ptr; 
ent  _node_ptr  =  new_ent_jiodejptr; 

} 

ent_count--; 

} 

first_gen_sub  =  TRUE; 
readstr(dap_fid,temp_str); 

db_ptr->edn_num  aen  =  str_to_nuni(temp  str); 
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gen  _sub_count  =  db_ptr->edn_nuni_gen; 
while  (  gen_sub_counl  !=  0  ) 

{ 

/*  the  gen  subtype  nodes  twe  allocated  and  filled  here  */ 
new_gen_ptr  =  rd_gen_sub  jiode(dap_fid); 
if  {  first_gen_sub  ==  TRUE  ) 

{ 

/*  special  case  of  first  generalization  node  */ 
db_ptr->edn_subptr  =  new_gen_ptr; 
gen_ptr  =  new_gen_ptr; 
first_gen_sub  =  FALSE; 

} 

else 

{ 

gen_ptr->gsn  _next_genptr  =  new_gen_ptr; 
gen_ptr  =  new_gen_ptr; 

} 

gen_sub_count--; 

} 

/*  Process  the  overlap  nodes  */ 

gen_ptr  =  db_ptr  ->  edn_subptr; 
while  (gen_ptr  !=  NULL) 

{  /*  begin  while  gen_ptr  <>  NULL  */ 
first_super  =  TRUE; 
readstr(dap_fid,temp_str); 

gen_ptr->gsn  jiuin_ent  =  str_to_num(tetnp_str); 
super_count  =  gen_ptr->gsn  _num_ent; 
while  (  super_count  !=  0  ) 

{ 

/*  the  subtypes  with  one  or  more  entity  supertypes  */ 

/*  nodes  are  allocated  and  filled  here  */ 

new_overlapent_ptr  =  rd_overlap_ent^ode(dap_fid, 

db_ptr->edn_entity); 

if  (  first_super  ==  TRUE  ) 

{ 

/*  the  special  case  of  the  first  overlap  ent  node  */ 
gen_ptr->gsn_entptr  =  new_overlapent_ptr; 
overlapent_ptr  =  new_overlap>ent_ptr; 
first_super  =  FALSE; 

} 

else 

{ 

overlapent_ptr->oen^ext3ame  =  new_overlapent_ptr; 
overlapent_ptr  =  new_overlapent_ptr; 

} 

--super_count; 

}  /*  end  super  type  node  */ 

first_8ub_super  =  TRUE; 
readstr(dap_fid,temp_8tr); 

gen_ptr->g8n_num  _sub  =  str_to_jium(tenip_str); 
sub_super_count  =  gen_ptr->g8n  jium_sub; 
while  (  sub _super_count  !=  0  ) 

{ 
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/*  the  subtype  supertypes  we  allocated  here  */ 
new_overlapsub_ptr  =  rd_overlap_sub_node(dap_fid, 

db_ptr->edn_subptr); 
if  (  first^ub_super  ==  TRUE  ) 

{ 

/*  special  case  of  first  overlapsub  node  */ 
gen_ptr->gsn_subptr  =  new_overlapsub_ptr; 
overlapsub_ptr  =  new  _overlapsub_ptr; 
first_sub_super  =  FALSE; 

} 

else 

{ 

overlapsub_ptr->osnjiext_naine  =  new_overlapsub_ptr; 
overlapsub_ptr  =  new_overlapsubjptr; 

} 

— sub_super  _count; 

}  /*  end  overlapsub  loop  */ 

gen_ptr  =  gen_ptr  ->  gsn_next_genptr; 

} 

/*  Process  the  sub  non  nodes  */ 
readstr(dapjid,temp_str); 

db_ptr->edn  _num  _nonsub  =  str_to  _num(temp_str); 
first_non_jub  =  TRUE; 
non_sub_count  =  db_ptr->edn_num_nonsub; 
while  (  non _sub_count  !=  0  ) 

{ 

/*  the  nonentity  subtype  nodes  we  allocated  and  filled  */ 
new_subnon_ptr  =  rd_3ub_non_node(dnp_fid); 
if  (  first_non_sub  ==  TRUE  ) 

{ 

/*  special  case  of  first  nonentity  subtype  node  */ 
db_ptr->edn_nonsubptr  =  new^ubnon_ptr; 
subnon_ptr  =  new_subnon  jptr; 
first_non_sub  =  FALSE; 

} 

else 

{ 

subnon_ptr->snnjiext_node  =  new^ubnonjptr; 
subnon_ptr  =  new^ubnon_ptr; 

} 

fir8t_value  =  TRUE; 

nuin_val  =  subnon_ptr->snn_num_yalues; 
while  (  nuni_val  !=  0  ) 

{ 

/*  the  value  nodes  we  allocated  and  filled  here  */ 
new_entval_ptr  =  rd_ent_yalue(dap_fid, 

subnon_ptr->snn_total_length); 
if  (  first_yalue  ==  TRUE  ) 

{ 

/*  special  case  of  first  actual  value  *  j 
subnon_ptr->snn_value  =  new_entval_ptr; 
entval_ptr  =  new_entval_ptr; 


first_yalue  =  FALSE; 

} 

else 

{ 

entval_ptr->ev_next_yalue  =  new  _entval_ptr; 
entval_ptr  =  new_entval_ptr; 

} 

--num_val; 

}  /*  end  actual  value  loop  */ 

— non_sub_count; 

}  /*  end  subtype  nonentity  loop  */ 

/*  Process  the  derived  nodes  */ 
readstr(dap^d,temp_str); 

db_ptr->edn_num_der  =  str_to_nuni(teinp_str); 
first  _non_der  =  TRUE; 
non  _der_count  =  db_ptr->edn_num_der; 
while  (  non _der_count  !=  0  ) 

{ 

/*  the  nonentity  derived  types  are  allocated  and  filled  here  *  j 
new_dernon_ptr  =  rd_der_non_node(dap_fid); 
if  (  first_non _der  ==  TRUE  ) 

{ 

/*  special  case  of  first  derived  type  nonentity  node  */ 
dbjptr->ednj;ionderptr  =  new_dernon_ptr; 
dernon_ptr  =  new_dernon_ptr; 
first_non_der  =  FALSE; 

} 

else 

{ 

dernon_ptr->dnn  _next  _nodc  =  new_dernon_ptr; 
dernon_ptr  =  new_dernon_ptr; 

} 

first_yalue  =  TRUE; 

num_yal  =  dernon_ptr->dnn  _num_yalues; 
while  (  num_val  !=  0  ) 

{ 

/*  the  value  nodes  are  allocated  and  filled  here  */ 
new_entval_ptr  =  rd_ent_yalue(dap_fid, 

dernon_ptr->dnn_total_length); 
if  (  first_yalue  ==  TRUE  ) 

{ 

/*  special  case  of  first  actual  value  */ 
dernon_ptr->dnn_value  =  new__entval_ptr: 
entval_ptr  =  new_entval_ptr; 
first_yalue  =  FALSE; 

} 

else 

{ 

entval_ptr->ev_next_yalue  =  new_entval_ptr; 
entval_ptr  =  new_entval_ptr; 

} 


— num_yal; 

}  /*  end  actual  value  loop  */ 

— non_der_count; 

}  /*  end  derived  type  non  entity  loop  */ 

/*  NOW  PROCESS  THE  FUNCTION  NODES  */ 

/*  First,  for  entity  nodes  */ 

ent_node_ptr  =  db_ptr->edn  _entity; 
while  (  ent_node_ptr  !=  NULL  ) 

{ 

first_func  =  TRUE; 

funct_count  =  ent  jodejptr->en_nuin_funct; 
while  (  funct_count  !=  0  ) 

{ 

/*  function  type  nodes  are  allocated  and  filled  here  */ 
new_func_ptr  =  rd_function_node(dap_fid,db_ptr); 
if  (  lirst_func  ==  TRUE  ) 

{ 

/*  the  special  case  of  first  function  node  */ 
ent_node_ptr->en_ftnptr  =  new^unc_ptr; 
func_ptr  =  new_func_ptr; 
first_func  =  FALSE; 

} 

else 

{ 

funcjptr->fnjiext_fntptr  =  new_funcjptr; 
func_ptr  =  new_func_p{r; 

} 

--funct_count; 

}  /*  end  function  loop  */ 
ent  ^odejptr  =  ent_node_ptr->en_next_ent; 

}  /*  end  while  loop  for  ent  function  nodes  */ 

/*  Now  Process  the  gen  sub  node  function  nodes  */ 

gen_ptr  =  db_ptr->edn_subptr; 
while  (  gen_ptr  !=  NULL  ) 

{ 

first_func  =  TRUE; 

funct_count  =  gen_ptr->gsnjiuni_funct; 
while  (  funct_count  !=  0  ) 

{ 

/*  the  function  type  nodes  are  allocated  and  filled  here  */ 
new_func_ptr  =  rd_function  _node(dap  _fid,dbjptr); 
if  (  first_func  ==  TRUE  ) 

{ 

/*  the  special  case  of  the  first  function  node  */ 
gen_ptr->gsn_ftnptr  =  new_func_ptr; 
func_ptr  =  new_func_ptr; 
first^unc  =  FALSE; 

} 


func_ptr->fn  jext_fntptr  =  new_func  j)tr; 
func_ptr  =  new_func_ptr; 

} 

funct_count--; 

}  /*  end  function  loop  */ 
genjptr  =  gen_ptr->gsn_next_genptr; 

}  /*  end  while  loop  for  gen  sub  function  nodes  */ 

}  /*  end  if  donejlag  !=  TRUE  loop  •/ 

}  /*  end  shema  makelist  loop  */ 

#iflef  EnExFl&g 

printf  ("Exit2  creat_dap_db_list"); 

#endif 

}  /*  End  creat_dap_dbj^ist  */ 

static  struct  ent _dbid _node  *rd_ent_dbidjiode  (  fid,  flag  ) 

FILE  *fid; 
int  *flag; 

{ 

struct  ent_dbidjiode  *db_ptr,  /*  pointer  to  database  node  */ 

*  ent_dbid_node _alloc(  );  /*  pointer  to  newly  *  j 
/*  allocated  database  node  * / 

char  temp_str  [NUMDIGIT  +  1];  /*  temp  string  to  hold  file  ID  */ 

#iflef  EnExFlag 

printf("Enter  rd_ent_dbid _node"); 

#endif 

/*  this  function  allocates  a  new  database  node  and  returns  a  pointer  */ 
/*  to  it  V 

/*  a  new  database  node  is  established  and  ptrs  are  initialized  */ 

db_ptr  =  entjdbid _node _alloc(  ); 
db_ptr->edn_nonentity  =  NULL; 
db_ptr->edn_entity  =  NULL; 
db_ptr->edn^ubptr  =  NULL; 
db_ptr->edn  _next_db  =  NULL; 
db_ptr->edn_nonsubptr  =  NULL; 
db_ptr->edn_nonderptr  =  NULL; 

readstr(fid,db_ptr->edn_name); 
if  (  db_ptr->edn  jame|0)  ==  ’$’  ) 

{ 

/*  when  file  becomes  empty  *  f 
‘flag  =  TRUE; 
free  (db_ptr); 

#iflef  EnExFlag 

printf("Exitl  ent_dbidjnode"); 

#endif 

return(NULL); 

} 

else 
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readstr(fid,temp_str); 

db_ptr->edn_nuin_nonent  =  str_to_nuin(temp_str); 

EnExFlag 

prinlf("Exit2  rd_ent_dbid_node"); 

#endif 

return{db_ptr); 

} 

}  /*  end  rd_ent_dbid_node  */ 

static  struct  ent_non _node  *rd_ent _non  jode(fid) 

FILE  *fid; 

{ 

struct  ent_non_node  *non_ent_ptr,  /*  pointer  to  base  type  */ 

/*  nonentity  node  */ 

*ent_non_node_alloc();  /*  pointer  to  newly  allocated  */ 

/*  nonentity  node  */ 

char  temp _str[NUMDIGIT  +  l];  /*  temp  string  to  read  fields  */ 

j*  this  function  allocates  a  new  base  type  nonentity  node  and  */ 

/*  returns  a  pointer  to  it  */ 

#iflef  EnExFlag 

printf  ("Enter  rd_ent_nonjiode"); 

#endif 

/*  get  new  base  type  nonentity  node  and  initialize  pointers  *  j 

non_ent_ptr  =  ent_non^ode _alloc(  ); 
non  _cnt_ptr->enn_yalue  =  NULL; 
non_ent_ptr->enn_next_node  =  NULL; 

/*  now  the  node  is  filled  in  by  reading  the  file  */ 

readstr(fid,non_ent_ptr->enn_name); 
readstr(fid,temp_str); 
non_ent_ptr->enn_type  =  temp_str[Oj; 
readstr  (fid ,  temp_str) ; 

non  _ent_ptr->enn_total_length  =  str_to_num(temp^tr); 
readstr(fid,temp_str); 

non_ent_ptr->enn_range  =  str_to  _num(teinp_str); 
readstr(fid,temp_str); 

non_ent_ptr->cnn_constant  =  str_to_nuin(temp  _str); 
readstr  (fid ,  temp_str) ; 

non_ent_ptr->enn_num_yalues  =  8tr_to_num(temp_8tr); 

#ifief  EnExFlag 

printf("Exit  rd_ent  jon_node"); 

#endif 

return(non_ent_ptr); 

}  /*  end  rd  ent  non  node  */ 


static  struct  ent_yalue  *rd_ent_value(fid,  length) 

FILE  *rid; 

int  length; 

{ 

struct  ent_yalue  *entval_ptr,  /*  pointer  to  def  for  value  */ 
*ent_yalue _alloc(  );  /*  pointer  fo  newly  allocated  */ 

/*  value  node  *  j 

char  teinp_str[NUMDIGIT  -I-  1);  /*  temp  string  to  read  fields  */ 
char  *var _str _alloc(); 

/*  this  function  allocates  a  new  value  node  and  returns  a  pointer  */ 
/*toit  »/ 

#iflef  EnExFlag 

printf("Enter  rd_ent_yalue  jode”); 

T^endif 

/*  get  the  new  value  node  and  initialize  ptrs  */ 

entval_ptr  =  ent_yalue _alloc(  ); 
entval_ptr->ev_next_yalue  =  NULL; 

/*  now  value  node  is  filled  in  by  reading  the  file  */ 

entvaljptr->ev_yalue  =  var_str  _alloc(length  +  1); 
readstr(fid,entvaljptr->ev_yalue); 

#ifief  EnExFlag 

printf("Exit  rd_ent_yalue_node"); 

#endif 

return(entval_ptr); 

}  /*  end  rd_ent_yalue  */ 


static  struct  ent_node  *rd_ent_node(fid) 

FILE  *fid; 

{ 

struct  ent  jode  *ent_node_ptr,  /*  pointer  to  entity  node  */ 
*ent_node_alloc(  );  /*  pointer  to  newly  allocated  */ 

/*  entity  node  */ 

char  temp _str[NUMDlGIT  +  1); 

/*  this  function  allocates  a  new  entity  node  and  returns  a  pointer  */ 
I*  to  it  */ 

#iBef  EnExFlag 

printf("Enter  rd_ent_node"); 

#endif 

/*  get  new  entity  node  and  initialize  values  */ 


ent_node_ptr  =  ent_node _alloc(  ); 
ent  _node_ptr->en_ftnptr  =  NULL; 
ent_node_ptr->en_next  _eiit  =  NULL; 

/*  now  the  entity  node  is  filled  in  by  reading  the  file  */ 

readstr(fid,ent_node_ptr->en  _name); 
readstr(fid,temp_str); 

ent_node_ptr->en_num_funct  =  str_to_num(temp_str); 
readstr(fid,temp_str); 

ent_jiode_ptr->en_terminal  =  str_to_nuin(tenip_str); 

#iflef  EnExFlag 

printf("Exit  rd_ent_node"); 

#endif 

return(ent  _node_ptr); 

}  /*  end  rd_ent_node  */ 


static  struct  function_node  *rd_function _node(fid,  db_ptr) 

FILE  *fid; 

struct  ent _dbid _node  *db_ptr; 

{ 

struct  function_node  *func  jtr,  /*  pointer  to  function  type  node  */ 
*function_node _alloc(  );  /*  pointer  to  newly  allocated  */ 
/*  function  type  node  */ 

char  temp_8tr[NUMDIGIT  +  l]; 
char  name_str[ENLength  +  Ij; 
int  num_yal, 
fir8t_yalue; 

struct  ent_yalue  *entval_ptr, 

*new_entval_ptr, 

*rd_ent_yalue(); 
struct  ent^ode  *ent_ptr; 
struct  gen_sub_node  *sub_ptr; 
struct  ent _non_node  *enon_ptr; 
struct  sub_non_node  *non_ptr; 
struct  der_non_node  *der_ptr; 
int  done_nag; 

/*  this  function  allocates  a  new  function  node  and  returns  a  pointer  */ 
/*  to  it  */ 

#i£lef  EnExFlag 

printf("Enter  rd_function  jode"); 

#endif 

I*  get  new  function  node  and  initialize  values  */ 

func_ptr  =  function_node _alloc(  ); 
func_ptr->fn_value  =  NULL; 
func_ptr->fn_entptr  =  NULL; 
func_ptr->fn_subptr  =  NULL; 
func_ptr^>fn_nonentptr  =  NULL; 
func_ptr->fn_nonsubptr  =  NULL; 


func  j)tr->fn_nonderptr  =  NULL; 
func_ptr->fn_next_fntptr  =  NULL; 

/*  now  the  function  node  is  filled  in  by  reading  the  file  */ 

readstr(fid,func_ptr->fn_name); 
readstr(fid,temp_str); 
func_ptr->fn_type  =  temp  _str[0); 
readstr(fid,temp_str); 

func_ptr->fnjrange  =  str_toj[ium(temp_8tr); 
readstr(fid,temp_str); 

func_ptr->fn_total_length  =  str_to_num(temp_str); 
readstr(fid,temp_str); 

func_ptr->fn_num_yalue  =  str_to_num(temp_str); 

first_yalue  =  TRUE; 

num_yal  =  func_ptr->fn  _num_yalue; 

while  (  num_yal  !=  0  ) 

{ 

/*  value  nodes  are  allocated  and  filled  here  */ 
new  _entval_ptr  =  rd_ent_yalue(rid, 

func_ptr->fn_total_length); 
if  (  first_value  ==  TRUE  ) 

{ 

/*  special  case  of  first  value  */ 
func_ptr->fn_value  =  new_entvaljptr; 
entval_ptr  =  new_entval_ptr; 
first_yalue  =  FALSE; 

} 

else 

{ 

entval_ptr->ev  _next_yalue  =  new  _entvaljptr; 
entvaljptr  =  new_entval  jtr; 

} 

— num_yal; 

}  /*  end  value  loop  */ 

readstr(fid,  name_str); 
if  {name_str[Ol  != 

{ 

done_flag  =  FALSE; 
ent_ptr  =  db_ptr->edn_entity; 
while  (done_nag  ==  FALSE) 
if  (strcmp(name_str,  ent_ptr->en  jame)  ==  0) 

{ 

done  _nag  =  TRUE; 
func_ptr->fn_entptr  =  ent  jptr; 

} 

else 

{ 

ent_ptr  =  ent_ptr->en_next_ent; 
if  (ent_ptr  ==  NULL)  done_flag  =  TRUE; 

} 

} 


readstr(fid,  name _str); 


if  {name_str[0]  !=  ’**) 

{ 

done_flag  =  FALSE; 
sub_ptr  =  db_ptr->edn_subptr; 
while  (done _flag  ==  FALSE) 
if  (strcmp(name_str,  subjptr->gsn_nanie)  == 
{ 

done_nag  =  TRUE; 

func  j)tr->fn_subptr  =  sub_ptr; 

} 

else 

{ 

sub_ptr  =  sub_ptr->gsn_nextjgenptr; 
if  (sub_ptr  ==  NULL)  done_nag  =  TRUE; 

} 

} 

readstr(rid,  name_str); 
if  (name _strjO]  !=  ’“’) 

{ 

done_nag  =  FALSE; 
enon_ptr  =  db_ptr->edn_nonentity; 
while  (donejRag  ==  FALSE) 
if  (strcmp(name_str,  enon_ptr->enn_name)  =• 
{ 

done  _flag  =  TRUE; 
func_ptr->fn_nonentptr  =  enon_ptr; 

} 

else 

{ 

enon_ptr  =  enon_ptr->enn_next_node; 
if  (enon_ptr  ==  NULL)  done__nag  =  TRUE; 

} 

} 

readstr(nd,  name_str); 
if  (name_str[0]  !=  ’*’) 

{ 

done^ag  =  FALSE; 
non_ptr  =  db_ptr->edn  _nonsubptr; 
while  (done_flag  ==  FALSE) 
if  (strcmp(name_str,  non_ptr->snn  name)  == 
{ 

done  Jlag  =  TRUE; 
func_ptr->fn_nonsubptr  =  non_ptr; 

} 

else 

{ 

non  _ptr  =  non_ptr->snn_next  jode; 
if  (non_ptr  ==  NULL)  done_flag  =  TRUE; 

} 

} 

readstr(nd,  name_str); 
if  (name  str[0]  !=  ’“’) 


done_nag  =  FALSE; 
der_ptr  =  db_ptr->edn  _nonderptr; 
while  (done_nag  ==  FALSE) 
if  (strcmp(name_jtr,  der_ptr->dnn  jame)  ==  0) 
{ 

donejlag  =  TRUE; 
func_ptr->fn  _nonderptr  =  der_ptr; 

} 

else 

{ 

der_ptr  =  der_ptr->dnn_riext_node; 
if  (der_ptr  ==  NULL)  done^ag  =  TRUE; 

} 

} 

readstr(fid,temp  _str); 

func  j)tr->fn_entnull  =  str_to_num(temp  _str); 
readstr(rid,temp_str); 

func_ptr->fn_unique  =  str_to  _num(temp  _str); 

#iflef  EnExFlag 

printf("Exit  rd_function  node"); 

#endif 

return  (func_ptr); 

}  /*  end  rd_function_node  */ 


static  struct  gen_sub_node  *rdjgen_3ub_node(fid) 

FILE  ‘fid; 

{ 

struct  gen _sub _node  *gen_ptr,  /*  pointer  to  generalization  node  */ 
*gen_sub _node _alloc(  );  /*  pointer  to  newly  allocated  */ 

/*  generalization  node  */ 

char  temp_striNUMDIGIT  +  1]; 

/*  this  function  allocates  a  new  generalization  node  and  returns  a  */ 
/*  pointer  to  it  */ 

#iQef  EnExFlag 

printf("Enter  rd_gen_sub_node"); 

#endif 

/*  get  new  generalization  node  and  initialize  ptrs  */ 

gen_ptr  =  gen_sub _node _alloc(  ); 
gen_ptr->gsn_entptr  =  NULL; 
gen_ptr->gsn_ftnptr  =  NULL; 
gen_ptr->gsn  _subptr  =  NULL; 
gen_ptr->gsn  _next_genptr  =  NULL; 

/*  now  the  generalization  node  is  filled  in  by  reading  the  file  */ 

readstr(fid,gen_ptr->gsn_name); 

readstr(fid,tenip_str); 

gen_ptr->gsn  jiumjFunct  =  str_to  _num(teinp_str); 
readstr  (fid ,  temp_str) ; 


gen_ptr->gsn_terininal  =  str_to  j[ium(temp_str); 
EnExFlag 

printf("Exit  rd_gen_sub_node")-, 

#endif 

return  (gen_ptr); 

}  /*  end  rd_gen_sub_node  */ 


static  struct  overlap_ent_node  *rd_overlap_ent  node  (fid,  ent_ptr) 

FILE  ♦fid; 

struct  ent _node  *ent_ptr; 

struct  overIap_ent  jode  *overlap_ptr,  /*  pointer  to  node  */ 
*overlap_ent_node _alloc(  );  /*  pointer  to  newly  */ 

/*  allocated  node  */ 

char  temp_str[NUMDIGIT  +  1]; 
char  name_3tr[ENLength  +  l]; 
int  done_flag; 

/*  this  function  allocates  a  new  subtype  with  one  or  more  entity  node  */ 
/♦  and  returns  a  pointer  to  it  */ 

#iflef  EnExFlag 

printfC'Enter  rd_overlap_ent_node"); 

#endif 

j*  get  new  node  and  initialize  pointers  */ 


overlap _ptr  =  overlap _ent_node _alloc(  ); 
readstrjfid,  name_str); 

donejfiag  =  FALSE; 
while  (done_nag  ==  FALSE) 

if  (strcmp(name_str.  ent_ptr->en_name)  ==  0) 

{ 

overlap_ptr->oen_name  =  ent_ptr; 
done_nag  =  TRUE; 

} 

else 

{ 

ent  j)tr  =  ent_ptr->en_next_ent; 

if  (ent  jptr  ==  NULL)  done_nag  =  TRUE; 

} 

overlap_ptr->oen_next  _name  =  NULL; 

#iflef  EnExFlag 

printf( "Exit  rd^verlap_ent_node") ; 

#endif 

ret  urn  ( over!  ap_ptr) ; 

}  /*  end  overlap_ent_node  */ 
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static  struct  overlap_sub_node  *rd_overlap_sub _node(rid,gen jptr) 

FILE  *fid; 

struct  gen _sub_node  *gen_ptr; 

{ 

struct  overlap_sub_node  *overlapsub_ptr,  /*  pointer  to  termimal  */ 

/*  subtype  nodes  */ 

*overlap_sub_node _alloc();  /*  pointer  to  newly  */ 

/*  allocated  node  */ 

char  temp_str[NUMDIGIT  +  1); 
char  name_3tr[ENLength  +  1|; 
int  done _nag; 

/*  this  function  allocates  a  new  terminal  subtype  node  and  returns  a  */ 
/*  pointer  to  it  */ 

#iflef  EnExFlag 

printf("Enter  rd_overlapsub^ode"); 

#endif 

/*  get  new  terminal  subtype  node  and  initialize  pointers  */ 

overlapsub_ptr  =  overlap_sub  _node  _alloc(); 
readstr(fid,  name_str); 

done_nag  =  FALSE; 
while  (donejlag  ==  FALSE) 

if  (strcmp(name_str,  gen_ptr->gsn _name)  ==  0) 

{ 

overlapsub_ptr->osn_name  =  gen_ptr; 
done_flag  =  TRUE; 

} 

else 

{ 

gen_ptr  =  gen  j)tr->g3n_next_genptr; 
if  (gen^ptr  ==  NULL)  done _flag  =  TRUE; 

} 

overlapsub_ptr->osn  _nextjame  =  NULL; 

#iflef  EnExFlag 

prin tf ( "  Exit  rd_o verlapsu  b  jode" ) ; 

#endif 

return(overlapsub_ptr); 

}  j*  end  rd_overlapsub_node  */ 

static  struct  subjion_node  *rd^ub jon_node(fid) 

FILE  ♦fid; 

{ 

struct  sub jonjiode  ♦subnon_ptr,  /♦  pointer  to  subtype  nonentity  */ 

/*  node  */ 

♦sub_non_node _alloc(  );  /*  pointer  to  newly  allocated  ♦/ 

/♦  nonentity  node  */ 

char  temp _str[NUMDIGIT  +  ij; 


/*  this  function  allocates  a  new  subtype  nonentity  node  and  returns  a  */ 

/*  pointer  to  it  */ 

f^iflef  EnExFlag 

printf("Enter  rd_sub_non_node''); 

#endif 

I*  get  new  subtype  nonentity  node  and  initialize  pointers  */ 

subnon_ptr  =  sub_non  jode _alloc(  ); 
subnon_ptr->snn_value  =  NULL; 
subnon_ptr->snn_next^ode  =  NULL; 

/*  now  the  subtype  nonentity  node  is  filled  in  by  reading  the  file  */ 

readstr(fid,subnon_ptr->snn_name); 
readstr(fid,temp_str); 
subnon_ptr->snn_type  =  temp_str(Oj; 
readstr(fid,temp_str); 

subnon  j)tr->snn_totaMength  =  str_to_num(temp_str); 
readstr(fid,temp_str); 

subnon  j)tr->snn_range  =  str_to_num(teinp_str); 
readstr(fid,temp_str); 

subnon_ptr->snn_nuin_vaIues  =  str_to_nuin(tenip_str); 

#iflef  EnExFlag 

printf("Exit  rd_sub_non_node"); 

#endif 

return(subnon_ptr); 

}  /*  end  rd_sub_non_node  */ 

static  struct  der_non_node  *rd_der_non_node{fid) 

FILE  ‘fid; 

{ 

struct  der _non _node  *dernon_ptr,  /*  pointer  to  derived  type  */ 

/*  nonentity  node  */ 

*der_non_node _alloc(  );  /*  pointer  to  newly  allocated  */ 

/*  derived  type  * / 

char  tenip_strjNUMDIGIT  +  l|; 

/*  this  function  allocates  a  new  derived  type  nonentity  node  and  returns  */ 
/*  a  pointer  to  it  */ 

#iflef  EnExFlag 

printf("Enter  rd_der _non_node''); 

#endif 

/*  get  new  derived  type  nonentity  node  and  initialize  pointers  */ 

dernon_ptr  =  der _non _node _alloc(  ); 
dernon_ptr->dnn_value  =  NULL; 
dernon_ptr->dnn  _next  _node  =  NULL; 


/*  now  the  derived  type  nonentity  node  is  filled  */ 


readstr{rid,dernon_ptr->dnii_name); 
readstr(fid,temp_str); 
dernon_ptr->dnn_type  =  temp_strjO]; 
readstr(fid ,  temp_str) ; 

dernon_ptr->dnn_total_length  =  str_to_num{temp_str); 
readstr(rid,teinp_str) ; 

dernon_ptr->dnn_range  =  str_to_num(teinp  _str); 
readstr(fid,temp_str); 

dernon_ptr->dnn_num_values  =  str_to  juin(temp_str); 

3^iflef  EnExFlag 

printf("Exit  rd_der_non_node"); 

#endif 

return(dernon_ptr); 

}  /*  end  rd  demon  node  */ 


APPENDIX  C 


THE  LIL  MODULE 


^include  <stdio.h> 

^include  "licommdata.deP' 

#include  "struct. def 
^include  "flags. deP' 
include  "dap. ext" 

^include  "lil.dcl" 

]anguage^nterface_layer() 

/*  This  proc  allows  the  user  to  interface  with  the  system.  */ 
j*  Input  and  output;  user  DAPLEX  requests  */ 

{ 

int  num; 

int  stop;  /*  boolean  flag  */ 
f^tfdef  EnExFlag 

printf  ("Enter  language_interface  J^ayerO);  ^ndif 
dap^nit(); 

/*  initialize  several  ptrs  to  different  parts  of  the  user  structure  */ 

/*  for  ease  of  access  */ 

dap_info_ptr  =  i£(cuser_dap_ptr->ui_Ii_type.li_dap); 

tran_info_ptr  =  &(dapj^nfo_ptr->dpi_dml_tran); 

first_reqjptr  =  l:(tran_info_ptr->ti  ^u^t_req); 

curr_req_ptr  -•  t(tran_i^nfo_ptr->ti_curr_req); 

stop  =  FALSE; 

while  (stop  ==  FALSE) 

{ 

/*  allow  user  choice  of  several  processing  operations  */ 
printf  ("Onter  type  of  operation  desiredO); 
printf  ("(1)  -  load  new  databaseO); 
printf  ("(p)  -  process  existing  databaseO); 
printf  ("(x)  -  return  to  the  operating  systemO); 
dap_info_ptr'>dap  _answer  =  get  _ajis(i£num); 

switch  (dap  info  ptr->dap  answer) 


case  ’1’:  /*  user  desires  to  load  a  new  database  */ 
loadjnew(); 
break; 

case  ’p’:  /*  user  desires  to  process  an  existing  database  */ 
process_old(); 
break; 

case  ’x’;  /*  user  desires  to  exit  to  the  operating  system  */ 

I*  database  list  must  be  saved  back  to  a  file  */ 

stop  =  TRUE; 

break; 

default:  /*  user  did  not  select  a  valid  choice  from  the  menu  */ 
printf  ("Orror  -  invalid  operation  selectedO); 
printf  ("Please  pick  againO); 
break; 

}  /*  end  switch  */ 

/*  return  to  main  menu  */ 

}  /*  end  while  */ 

#fdef  EnExFlag 

printf  ("Exit  language_interface_layerO);  ^^tendif 
}  /*  end  language_interface_layer  */ 
dap_i^nit()  { 

#rdef  EnExFlag 

printf  ("Enter  dapj^nitO);  #endif 

#rdef  EnExFlag 
printf  ("Exit  dap_initO);  ?(<endif 

}  /*  end  dap_init  */ 

load_new() 


/*  This  proc  accomplishes  the  following;  */ 

/*  (1)  determines  if  the  new  database  name  already  exists,  */ 

/*  (2)  adds  a  new  header  node  to  the  list  of  schemas,  */ 

/*  (8)  determines  the  user  input  mode  (file/terminal),  */ 


/*  (4)  reads  the  user  input  and  forwards  it  to  the  parser,  and  */ 
/*  (5)  calls  the  routine  that  builds  the  template/descriptor  files  */ 


{ 


int  num; 

int  stop;  /*  boolean  flag  */ 

int  more_input;  /*  boolean  flag  */ 
int  proceed;  /*  boolean  flag  */ 

struct  ent_dbid_node  *db_]^ist_ptr,  /*  ptr  to  the  current  db  */ 

*new_ptr,  /*  ptr  to  a  new  db  structure  */ 

*ent_dbid^ode _alloc();  /*  ptr  to  allocated  db  */ 

^if^rdef  EnExFlag 

printf  ("Enter  load_newO);  ifendii 

/*  prompt  user  for  name  of  new  database  */ 

printf  ("[7;7m0nter  name  of  database  — ->[0;0m  "); 

readstr  (stdin,  dap_i^nfo_ptr->dpi_curr_db.cdi_dbname); 

to_caps  (dap_info_ptr->dpi_curr_db.cdi_dbname); 

db_list_ptr  =  dbs_dap_head_ptr.dn_dap; 

stop  =  FALSE; 

while  (stop  ==  FALSE) 

{ 

/*  determine  if  new  database  name  already  exists  */ 

/*  by  traversing  list  of  entity-relation  db  schemas  */ 
if  ((strcmp(db_list_ptr->edn _name, 

dap  jnfo_ptr->dpi_curr_db.cdi  _dbname))==  0) 

{ 

printf  ("Orror  -  db  name  already  exbtsO); 

printf  ("l7;7mPlease  reenter  db  name  — >[0;0m  "); 

readstr  (stdin,  dap_info_ptr->dpi_curr_db.cdi_dbname);  to^caps  (dap^nfo_ptr- 

>dpi_curr_db.cdi_dbname); 

db_list_ptr  =  dbs_dap  _head_ptr.dn_dap; 

}  /*  end  if  V 

else  /*  check  for  last  database  of  the  list  */  if  (db_list_ptr->edn_next_db  == 
NULL)  stop  =  TRUE;  else 

/*  increment  to  next  database  */ 
db_list_ptr  =  db_list_ptr->edn  _next  _db; 

}  /*  end  while  */ 

/*  continue  -  user  input  a  valid  ’new’  database  name  */ 

j*  add  new  header  node  to  the  list  of  schemas  and  fiil-in  db  name  */ 

j*  append  new  header  node  to  dbjist  &  init  relevant  user  stucture  ptrs  */ 
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new_ptr  =  ent_dbid_node  _alloc(); 

strcpy  (new_ptr->edn_naine,  dap^nfoj)tr->dpi^urr _db.cdi _dbname); 

/*  new_ptr->dpidn _num^et  =  0;  */ 

/*  new_ptr->dpidn _nuni_rec  =  0;  */ 

/*  new_ptr->dpidn Jiirst_set  =  NULL;  */ 

/*  new_ptr->dpidn_flrst^ec  =  NULL;  */ 

/*  new_ptr->dpidn_next_db  =  NULL;  */ 
db_list_ptr->edn_next_db  =  new_ptr; 
dap_info_ptr->dpi_curr_Qb.cdi_db.dn  _dap  =  new_j)tr; 
dap_info_ptr->dpi_curr_db.cdi  _attr.an_dattr_ptr  —  NULL; 

/*  check  for  user’s  mode  of  input  */ 

more_input  =  TRUE; 

while  (more_input  ==  TRUE) 

{ 

/*  determine  user’s  mode  of  input  */ 

printf  C'Onter  mode  of  input  desiredO); 

printf  ("(f)  -  read  in  database  description  from  a  fileO); 

printf  ("(x)  -  return  to  the  to  main  menuO); 

dapj.nfo  j)tr->dap  _answer  =  get  _ans(i£num); 

switch  (dap^nfo_ptr->dap_answer) 

{ 

case  T:  /*  user  input  is  from  a  file  *  j 

read_transaction _file();  if  {dap_info_ptr->dap_error  !=  ErrReadFile) 

{  /*  file  contains  transactions  */  /*  dbd  stands  for 

database  description  */  dbd_to  _KMS();  free_requests(); 

if  (dap_info_ptr->dap_error  !=  ErrCreateDB)  { 

/*  no  syntax  errors  in  creates  */ 

build  _ddl_files(); 

Kernel_Controller();  }  /*  end  if  */  }  /*  end  if  */ 

break; 

case  ’x’:  /*  exit  back  to  LIL  */ 
more_input  =  FALSE; 
break; 

default:  /*  user  did  not  select  a  valid  choice  from  the  menu  */ 
printf  ("Orror  -  invalid  input  mode  selectedO); 
printf  ("Please  pick  againO); 
break; 


}  /*  end  switch  */ 


if  (dap_info_ptr->dap_eiTor  ==  ErrCreateDB)  /*  errors  in  creates  so  exit  this  loop  */ 
more_input  =  FALSE; 
dap_info_ptr->dap_error  =  NOErr; 

}  /*  end  while  */ 

#fdef  EnExFlag 

printf  ("Exit  load_newO);  #endif 
}  /*  end  load_new  */ 
process_old() 

/*  This  proc  accomplishes  the  following:  */ 

/*  (1)  determines  if  the  database  name  already  exists,  */ 

/*  (2)  determines  the  user  input  mode  (file/terminal),  */ 

I*  (3)  reads  the  user  input  and  forwards  it  to  the  parser  */ 

{ 

int  found,  more^nput;  /*  boolean  flags  */ 

int  num; 

struct  ent_dbid jiode  *db_list  jtr;  /*  ptr  to  the  current  database  */ 

#rdef  EnExFlag 

printf  ("Enter  process_oldO);  ?^ndif 

/*  prompt  user  for  name  of  existing  database  * / 
printf  ("(7;7m0nter  name  of  database  — >[0;0m  "); 
readstr  (stdin,  dap_info_ptr->dpi_curr_db.cdi_dbname); 
to_caps  (dap_jnfo_ptr->dpi_curr_db.cdi_dbname); 
db_list_ptr  =  dbs_dap  _head_ptr.dn_dap; 

found  =  FALSE; 
while  (found  ==  FALSE) 

{ 

/*  determine  if  database  name  does  exist  *  / 
j*  by  traversing  list  of  entity-relation  schemas  */ 

if  (strcmp(dap^nfo_ptr->dpi_curr_db.cdi_dbname,db_list_ptr->edn_name)==  0) 
found  =  TRUE; 


dbjist_ptr  =  db_list_ptr->edn  jext_db; 

/*  error  condition  c&uses  end  of  list(’NULL’)  to  be  reached  */ 
if  (dbjist  j)tr  ==  NULL) 

{ 

printf  ("Orror  -  db  name  does  not  existO); 
printf  ("[7;7inPlease  reenter  valid  db  name  ---->[0;0m  "); 
readstr  (stdin,  dap^nfo_ptr->dpi_curT_db.cdi_dbname); 
(dap_info  jtr->dpi_curr_db.cdi_dbname); 

db_list_ptr  =  dbs_dap  _head_ptr.dn_dapi 
}  r  end  if  V 

}  /*  end  else  */ 

}  /*  end  while  */ 

/*  continue  -  user  input  a  valid  existing  database  name  *  j 

j*  determine  user’s  mode  of  input  *  j 

more_jnput  =  TRUE; 

while  (more_input  ==  TRUE) 

{ 

printf  ("Onter  mode  of  input  desiredO); 

printf  ("(f)  -  read  in  a  group  of  DAPLEX  requests  from  a  fileO); 
printf  ("(tj  -  read  in  DAPLEX  requests  from  the  terminalO); 
printf  ("(x)  -  return  to  the  previous  menuO); 
dap_info_ptr->dap_answer  =  get  _ans(&num); 

switch  (dap_info_ptr->dap ^answer) 

{ 

case  T:  /*  user  input  is  from  a  file  */ 

read_transaction_file();  dapreqs_to  _KMS(); 

free_requests();  break; 

case  ’t’:  /*  user  input  is  from  the  terminal  */ 
read_terminal(); 

dapreqs_to  _KMS();  freej;equests();  break; 

case  ’x’:  /*  user  wishes  to  return  to  LIL  menu  */ 
more_input  =  FALSE; 
break; 

default;  /*  user  did  not  select  a  valid  choice  from  the  menu  */ 
printf  ("Orror  -  invalid  input  mode  selectedO); 
printf  ("Please  pick  againO);  break; 


to_caps 


APPENDIX  D 


THE  KMS  MODULE 


/*  Last  Date  Modified:  12  Nov  85  /  ja  /  building  db  description  ops  */ 


{ 


^include  <stdio.h> 
#include  "licommdata.der' 
#include  "struct. def 
#include  "dap. ext" 

# include  "flags. deP' 


int  creating  =  FALSE;  int  serror;  int  in;  int  ini;  int  in2;  int  inS;  int  in4;  int  in5;  int  add; 
int  present;  int  there;  int  i,  j;  int  move,  nmove;  int  b;  int  nsub,esub;  int  curr _op;  int 
check_ids;  int  dummy,  dummy2;  int  ada_expression; 

char  temp_str[NUMDIGIT  +  Ij;  char  db[DBNlength  +  l];  char  temp_yalue|ENlength  +  1];  char 
temp[ENlength  +  11:  char  type_name_id[ENlength  +  l|; 

struct  ent_dbid_node  *db_ptr;  struct  ent  jonjnode  *non_ent_ptrl, 

*non_ent_j)tr2;  struct  ent_yalue  *entval_ptrl, 

*entval_ptr2;  struct  sub_non_node  *subnon_ptrl, 

*subnon_ptr2;  struct  der_non_node  *dernon_ptrl, 

*dernon_ptr2;  struct  ent_node  *ent_ptrl, 

*ent_ptr2; 

*new_ent_ptr;  struct  gen _sub _node  *gen_ptrl, 

*gen_ptr2; 

*new_gen_ptr;  struct  overlap_ent_node  *overlapent_ptrl, 

*overlapent_ptr2;  struct  overlap_sub_node  *overIapsub_ptrl, 

*overlapsub_ptr2;  struct  function_node  *func_ptrl, 

*func  _ptr2;  struct  dap  _kms_info  *km8_ptr;  struct  dap_kms_info 

*dap Jim8_info _alloc();  struct  ident_list  *id_ptr, 

*temp_ptr, 

*new_temp_ptr, 

*new_id  _ptr;  struct  ent  _non_node  •dap_ent  _non  _node  _alloc();  struct 

ent _node  *dap_ent_node_alloc();  struct  function_node  *dap_func_node _^loc();  struct 

sub  _non  _node  *dap  _sub_non_node  _alloc();  struct  der  jion_node 
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dap_der _non _node _a.lloc();  struct  ent_ya]ue  *dap _ent_yalue _alloc();  struct  dap_creale_list 

*create_listl, 

*create_list2, 

*dap_create  Jist  _alloc(); 

%union 

{ 

char  str[20|; 

} 

%token  DATABASE  %token  ENTITY  %token  OVERLAP  %token  TEMPORARY  %token 
TRUE  %token  FALSE  %token  END  %token  IS  %token  WITH  %token  WITHIN  %token 
UNIQUE  %tokeii  TYPE  %token  SUBTYPE  %token  NEW  %token  EMPTY  %token 
CREATE  9?token  CONSTANT  %token  AND  %token  OR  %token  XOR  %token  THEN 
9?token  ELSE  ?aoken  FOR  %token  EACH  %token  DELTA  %token  NULL  %token  WITH- 
NULL  %token  WITHOUTNULL  %token  SET  %token  IMAGE  %token  POS  ®?token  VALUE 
/otoken  VAL 

%token  <str>  IDENTIFIER  %token  <str>  NUMERIC _LITERAL  %token  <str>  STRING 
%token  <str>  CHARACTER_STRING  %token  <str>  LITERAL_STRING  %token  <str> 
FLOAT  Otoken  <str>  INTEGER  %token  <str>  BOOLEAN  %token  <3tr>  RANGE 
%token  <str>  DIGITS  %token  <str>  ELIPSES  %token  <str>  COLON  %tokcn  <str> 
SEMICOLON  %token  <str>  DOT  %token  <str>  COMMA  %token  <str>  ASSIGN  %token 
<str>  LP  %token  <str>  RP  %token  <str>  HYPHEN  %token  <str>  IMPLY 

?Stoken  <str>  subtype^ndicator  %token  <str>  subtype_indication 
%start  statement 

%% 

statement:  ddl_statement 

{ 

YYACCEPT; 

} 


ddl  statement:  database  speciHcation 


proc_free^d_list  ( ) ; 


database_specifjcation:  TEMPORARY  database_definition 
I  database_definition 
1 

database_definition:  DATABASE 
{  #iaef  HYacFlag 

printf("Database  in  database^defmition  recognizedO);  ^ndif 
check^ds  =  TRUE; 
creating  =  TRUE; 

} 

visiblc_part  end_database 
1 

end_database:  end _rnodule 

end  module:  END 


check_ids  =  FALSE; 

} 

name_id 

{ 

db_ptr  =  cuser_dap_ptr->ui_li_type.li_dap.dpi_curr_db.cdi_db.dn_dap; 
strcpy(db,db_ptr->edn_name); 

if(strcmp(tenip_yalue,  db_ptr->edn _name)  !=  FALSE) 

{ 

seiTor  =  0; 

proc_eval_error(8error) ; 

YYACCEPT; 


vi8ible_part:  name_id  /*  =’s  [A-Z)[A-Z]  in  LEX  */ 


-  -  .  » 


: .  A 


►  *  I 

^  •  •  s  f  \ 


«*•  **•  '»"•  V**  *'■.*■.**  «*“  V**  k*  *  ■**  W*"  V"*  V  •  W*  ' 
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/*  the  ent_dbid_node  is  located  and  compared  for  correctness  */ 

{ 

db_ptr  =  cuser  _dap_ptr->ui_li_type.li_dap.dpi_curr^b.cdi_db.dn^ap; 
strcpy(db,db_ptr->edn_name); 

if  (strcmp(db_ptr->edn  jame,  temp_value)  !=  FALSE) 

{ 

serror  =  0; 

proc_eval  _error(serror); 

YYACCEPT; 

} 

} 

IS  declarative  item  list 


declarative_jtem_list:  declarative _[tem 

I  declarative_item_list  declarative_item 

declarative^tem:  declaration 
I  consistency_rule 

consistency_rule:  overlap^ule 
I  uniqueness_rule 
> 

overlap_rule:  OVERLAP 

/*  the  types  are  checked  to  insure  that  they  are  terminal  subtypes  */ 

{ 

serror  =  14; 
check_ids  =  FALSE; 
curr_op  =  Overlap; 

} 

namel_list 

{ 

kms_ptr->dki_overrirst_ptr  =  kms_ptr->dki^emp_ptr; 
kms_ptr->dki_temp_ptr  =  NULL; 
ov_ptr  =  kms_ptr->dki_overfirst  jptr; 


.*  V  V 

vVv 
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END 


MICROCOPY  RESOLUTION  TEST  CHART 

'■•’•■'NAl  BUPMI'  Of  c»'NDA'?OS  1963  A 


in  =  FALSE; 

new_gen_ptr  =  db_ptr->edn_subptr; 
gen_ptr  =  new_gen_ptr; 
while  (ov_ptr  !=  NULL) 

{ 

while  ((gen_ptr  !=  NULL)  iiL  (in  TRLE)) 

{ 

if  (strcmp(ov j)tr->iljiame,  gen_ptr->gsn jiame)  ==  FALSE) 

{ 

in  =  TRUE; 

} 

else 

{ 

new_gen_ptr  =  gen_ptr->gsn_next_jenptr; 
gen_ptr  =  new_gen_ptr; 

} 

} 

if  (in  ==  TRUE) 

{ 

new_ov_ptr  =  ov  jptr->il  jext; 
ov_ptr  =  new_ov_ptr; 
new_gen_ptr  =  db_ptr->edn_subptr; 
gen_ptr  =  new_gen_ptr; 
in  =  FALSE; 

} 

else 

{ 

proc_e  V  al_error(serror); 

} 

} 

} 

WITH  nameljist  SEMICOLON 

{ 

in  =  FALSE; 

new_temp_ptr  =  k7ns_ptr->dki_teinp_ptr; 
temp_ptr  =  new_tenip_ptr; 
new_gen_ptr  =  db_ptr->edn_subptr; 
gen_ptr  =  new_gen_ptr; 


V  .  •v 
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new  _overlapsub_ptr  =  gen_ptr->gsn  _subptr; 
overlapsub_ptr  =  new_overlapsub_j>tr; 
while  (temp_ptr  !=  NULL) 

{ 

while  {(gen_ptr  !=  NULL)  tiSi  (in  ==  FALSE)) 

{ 

if  (strcmp(gen  j)tr->gsn _name,  temp_ptr->il _namc)  ==  FALSE) 

{ 

in  =  TRUE; 

new_ov_ptr  =  kms_ptr->dki_overfirst_ptr; 
ov_ptr  =  new_ov_ptr; 
while  (ov  j)tr  !=  NULL) 

{ 

if  (overIapsub_ptr  ==  NULL) 

{ 

gen_ptr->gsn^ubptr  =  dap_overlap_sub_node  _alloc(); 
new_overlapsub_ptr  =  gen_ptr->gsn_subptr; 
overlapsub_ptr  =  new_overlapsub_ptr; 
ov_ptr->il_name  =  overlapsub_ptr; 
overlapsub_ptr->osn_najne  =  ov_ptr->il_name; 
overlapsub_ptr->oen_iiext_name  =  NULL; 

} 


while  (overlapsub_ptr->oen_naine  !=  NULL) 
overlapsub_ptr  =  overlapsub_ptr->oen_next_jiaine; 
overIapsub_ptr->oen_next^ame  =  dap_overlapjub_node_alloc(); 
new_overlapsub_ptr  =  overlapsub_ptr->oen_next_naine; 
overlapsub_ptr  =  new_overlnpsub_ptr; 
ov_ptr->il_name  =  overlapsub_ptr; 
overlapsub_ptr->osn  jame  =  ov_ptr->il_name; 
overlapsub_ptr->oen_next  jame  =  NULL; 


new_ov_ptr  =  ov_ptr->iljiext; 
ov_ptr  =  new_pv_ptr; 


/*  if  the  temp_yalue  is  found  in  the  function  */ 

/*  node  the  unique  field  in  the  function  node  */ 

/*  is  initialized  to  true,  else  an  error  mess-  */ 

/*  is  initiated  */ 

in  =  TRUE; 
there  =  FALSE; 

new_func_ptr  =  ent  _node_ptr->en_ftnptr; 
func_ptr  =  new_func_ptr; 
new_temp_ptr  =  kms_ptr->dkijtemp_ptr; 
temp_ptr  =  new_temp_ptr; 
while  (temp_ptr  !=  NULL) 

{ 

while  (func_ptr  !=  NULL) 

{ 

if(strcmp(temp_ptr->il_name,  func_ptr->fn_name)  ==  FALSE) 

{ 

there  =  TRUE; 

func_ptr->fn_unique  =  TRUE; 

} 

else 

{ 

new  Junc_ptr  =  func_ptr->fn_next_fntptr; 
func_ptr  =  new_func_ptr; 

} 

} 

if  (there  ==  TRUE) 

{ 

new_temp_ptr  =  temp_ptr->iljext; 
teinp_ptr  =  new_temp_ptr; 
new_func_ptr  =  ent_node_ptr->en_ftnptr; 
func_ptr  =  new_func_ptr; 
there  =  FALSE; 

} 

else 

{ 

proc_eval_eiTor(seiTor); 

} 

} 
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new_ent  _node_ptr  =  ent_nodej>tr->en_nexl_ent; 
ent  jode_ptr  =  ncw_ent  ^ode_ptr; 

} 

} 

if  (in  ==  FALSE) 

{ 


/*  The  temp_yalue  is  compared  to  each  value  in  the  */ 
/*  gen_sub _node.  If  the  value  is  not  there,  an  error  */ 
/*  message  is  initiated.  */ 


while  (gen_ptr  !=  NULL) 

{ 

if  (strcmp(gen_ptr->gsn_name,  temp_yalue)  ==  FALSE 

{ 

in  =  TRUE; 
there  =  FALSE; 

new_funcj)tr  =  gen_ptr->gsn_flnptr; 
func_ptr  =  new_func_ptr; 
new_temp_ptr  =  kms_ptr->dki_temp_ptr; 
temp_ptr  =  new_temp_ptr; 
while  (temp_ptr  !=  NULL) 

{ 

while  (func_ptr  !=  NULL) 

{ 

if(strcmp(temp_ptr->il_name,  func_ptr->fn_name) 

{ 

there  =  TRUE; 

func_ptr->fn_unique  =  TRUE; 

} 

else 

{ 

new_func_ptr  =  funcjptr->fnjiext_fntptr; 
func  ptr  =  new_func_ptr; 


new_temp  _ptr  =  temp_ptr->il  jext; 
temp_ptr  =  new_temp_ptr; 
new_func_ptr  =  gen  jode_ptr->g9n_ftnptr; 
func_ptr  =  new_func_ptr; 
there  =  FALSE; 

} 

else 

{ 

proc  _eval_error(serror); 

} 

} 

} 

else 

{ 

ne'w_gen_ptr  =  gen_ptr->gsn_next_genptr; 
gen_ptr  =  new_gen_ptr; 

} 

} 

} 

if  (in  ==  FALSE) 
proc  _ev  &l_eiTor  ( serror ) ; 
check^ds  =  TRUE; 

} 

1 

declaration:  number_declaration 
!  type_declaration 
{  subtype_declaration 

n  um  ber_dec  laration : 

{ 

serror  =  1; 
check_id9  =  TRUE; 

} 

identifier  list  COLON  CONSTANT  ASSIGN  simple  const  SEMICOLON 


teinp_ptr  =  kms_ptr->dki_tenip  _pir; 
while  {temp_ptr  !=  NULL) 

{ 

/*  At  this  point  ent  jon_node’s  we  filled  with  the  * j 
/*  information  previously  allocated  in  the  kms  info  */ 

/*  structure.  The  amount  of  nodes  is  dependent  on  */ 

/*  the  amount  of  names  in  the  temp  structure.  * / 

ent^on_ptrl  =  dap_ent  jon_node  _alloc(): 
strcpy(ent_non_ptrl->enn_name,  temp_ptr->iljiame); 
ent^on_ptrl->enn_type  =  kms_ptr->dki_ent _non.enn_type  ; 
ent_non_ptrl->enn_total_|ength  = 

kms_ptr->dki_ent_non.enn_total_length  ; 
ent_non_ptrl->enn_range  =  kms_ptr*>dki_ent _non.enn_range  ; 
ent^on_ptrl->enn_num_yalues  = 

kms_ptr->dki_ent _non.enn_num_yalues  ; 
ent  jon_ptrl->enn_value  =  kms_ptr->dki_ent_non.enn_yalue  ; 
kms_ptr->dki_ent^on.enn_value  =  NULL; 
ent_non_ptrl->enn_constant  = 

kms_ptr->dki_ent_non.enn_constant  ; 
ent_non_ptrl->enn  _next_node  =  NULL; 

ent_non_ptr2  =  db_ptr->edn_nonentity; 

if  (ent_non_ptr2  ==  NULL) 
db_ptr->edn_nonentity  =  entjion_ptrl; 


while  (ent _non_ptr2->enn _next _node  !=  NULL) 
ent_non_ptr2  =  ent_non_ptr2->enn_next_node; 
ent_non_ptr2->enn_next_node  =  ent  jon_ptrl; 

} 

ent  _non_ptrl  =  NULL; 
temp_ptr  =  temp_ptr->il_next; 

} 

check_ids  =  FALSE; 


simple_const:  INTEGER  /*  dap _km8_info  structures  are  built  for  subsequent  */ 
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/*  nonentity  node  insertion  into  the  schema 


/ 


{ 

kms_ptr->dki_ent_non.enn_type  =  ’i’; 
kms_ptr->dki_ent_non.enn_total_length  =  INTLength; 
kms_ptr->dki_ent_non.enn^ange  =  FALSE; 
kms_ptr->dki_ent  jon.enn_num_values  =  1; 
kms_ptr->dki_ent_non.enn_constant  =  TRUE; 
kms_ptr->dki_ent_non.enn_yaJue  =  dap_ent_yalue  _alloc() 
kms_ptr-  >dki_ent  jon.enn_value-  >ev_yalue  = 
var_str _alloc(  strlen($l)  +  1  ); 
strcpy(kms_ptr->dki_ent _non.enn_value->ev_yalue,  $1); 
kms_ptr->dki_ent_non.enn_value->ev_next_value  =  NUL' 

} 

FLOAT 

{ 

kmsjptr->dki_ent  jon.enn_type  =  T; 
kms_ptr->dki_ent_non.enn_total_length  =  FLTLength; 
kms_ptr->dki_ent  jon.enn_range  =  FALSE; 
kms_ptr->dki_ent_non.ennj;ium_values  =  1; 
kms_j)tr->dki_ent_jion.enn_constant  =  TRUE; 
kmsjptr->dki_ent_non.enn_yalue  =  dap_ent_yalue  _alloc() 
kms_ptr->dki_ent  _non.enn_value->ev_yalue  = 
var_str _alloc(  strlen($l)  +  1  ); 
strcpy(kms_ptr->dki_ent  jon.enn_yalue->ev_yalue,  $1); 
kms_ptr->dki_ent_non.enn_yalue->ev  jext_yalue  =  NUL 

} 


type_declaration;  TYPE 

cuiT_op  =  Typels; 
check_ids  =  FALSE; 
serror  =  2; 

} 

name_id 

{ 

strcpy(temp_name_id,  temp_yalue); 
check  ids  =  TRUE; 


serror  =  9; 

} 

IS  type_dermition  SEMICOLON 

/*  the  following  switch  statement  allocates  a  nonentity  */ 

/*  derived,  or  entity  node  to  the  schema  dependent  upon  */ 

/*  the  value  of  curr_op  */ 

{ 

curr_op  =  Checkids; 
switch(curr_op) 

{ 

case  NonEnt: 

ent_non_ptrl  =  dap_ent_non_node  _alloc(); 
strcpy(  ent_non_ptrl->enn  name,  temp _name_id  ), 
ent  jon_ptrl->enn_type  =  km8_ptr->dki_ent_non.enn_type  ; 
entjnon_ptrl-'>enn_totaMength  = 

kms_ptr->dki_ent _non.enn_total_length  ; 
ent_non  j)trl->enn_range  =  kms_ptr->dki_ent_non.enn_range 
ent_non_ptrl->enn_num_yalues  = 

kms_ptr->dki_ent_non.enn_num_values  ; 
ent_nonjptrl->enn_value  =  kms_ptr->dki_ent  _non.enn_yalue 
kms_ptr->dki_ent_non.enn_yaluc  =  NULL; 
ent_non_ptrl->enn_constant  = 

kms_ptr->dki_ent_non.enn_constant  ; 
ent_non_ptrl->enn_next  _node  =  NULL; 

ent_non_ptr2  =  db_ptr->edn_nonentity; 

if  (ent_non_ptr2  ==  NULL) 
db_ptr->edn_nonentity  =  ent_non_ptrl; 
else 
{ 

while  (entjrion_ptr2->enn_next_node  !=  NULL) 
ent_non_ptr2  =  ent_non_ptr2->enn_next_node; 
ent_non_ptr2->enn_next  jiode  =  ent_nonjptrl; 

} 

ent_non  j>trl  =  NULL; 
break; 


case  Derived: 


dernon_ptrl  =  dap_der_non_no<]e  _ailloc(); 
strcpyf  dernon_j)trl->dnn _name.  temp_name_id  ); 
dernon_ptrl->dnn_type  =  kms_ptr->dki_der_non.dnn_type  ; 
dernon_ptrl->dnnJ,otal_|ength  = 

kms_ptr->dki_der_non.dnn_total_length  ; 
dernon_ptrl->dnn_rang«  =  kfns_ptr->dki_der  _non.dnn_range 
demon  j)trl->diin_num_yalues  = 

kms_ptr->dki_der_non.dnn jiuni_yalues  ; 
demon_ptrl->dnn_yalue  =  kms_ptr->dki_der  _non.dnn_ya]ue 
kms_ptr->dki_der_non.dnn_yalue  =  N'ULL; 
dernon_ptrl->dnn_next_node  =  NULL; 
dernon_ptr2  =  db_ptr->edn_nonderptr; 
if  (dernon_ptr2  ==  NULL) 
db_ptr->edn_nonderptr  =  dernon_ptrl; 


while  (dernon_ptr2->dnn_next_node  !=  NULL) 
demon  _ptr2  =  demon_ptr2->dnn_next_node; 
dernon_ptr2->dnn_next_node  =  demon  j)trl; 

} 

dernonjptrl  =  NULL; 
break; 

case  Entity; 

/*  check  if  name_id  is  on  the  ent  list  of  the  schema  */ 

} 


incomplete_type_declaration 


namejd:  IDENTIFIER 

/*  this  rule  assigns  IDENTIFIER  to  the  variable  temp_yalue  */ 
j*  and  inserts  it  into  the  id  structure  of  dap _kms^nfo  for  */ 

/*  subsequent  comparisons  of  uniqueness  */ 


strcpy(temp_value,$l); 

id  ptr  =  kmsptr->dki_id jptr; 


kms_ptr->dkij^d_ptr  =  dap_[dent  Jist  _ailloc(); 
id_ptr  =  kms_ptr->dki_id_ptr; 


nmove  =  FALSE; 
new_id_ptr  =  id_ptr; 
while(id_ptr  !=  NULL) 

{ 

if  (strcmp(id_ptr->il_name,  teinp_yalue)  ==  FALSE) 

{ 

nmove  =  TRUE; 


new_id  _ptr  =  id_ptr; 
id  j)tr  =  id_ptr->il_next; 


if((nmove  ==  FALSE)  Uk.  (curr_op  ==  Checkids)) 

{ 

new^d  _ptr->il  _next  =  dap_ident_list  _alloc(); 
new_id_ptr  =  new_id  jitr->il_next; 
strcpy(new_idjptr->il _name,  temp_yalue); 
new_id_ptr->il_next  =  NULL; 

} 


if( (nmove  ==  TRUE)  kk  (  uiT_op  =  Checkids)) 
proc_eval_error(serror) ; 


incomplete_type_declaration:  TYPE 
/*  entity  */ 


.••'.vV- 


check_ids  =  TRUE; 
serror  =  3; 

) 

name_id  SEMICOLON 

/*  At  this  point  a  check  is  made  to  see  if  the  */ 

/*  IDENTIFIER  is  already  in  the  ent  jode.  If  it  */ 

/*  is,  an  error  is  produced.  If  it  is  not,  it  is  */ 

/*  added  to  the  schema.  */ 

{ 

in  =  F.4LSE; 

ent_node_ptrl  =  db_ptr->edn_entity; 
ent_node_ptr2  =  ent^odejitrl; 
while  (ent  jiode_ptr2  !=  NULL) 

{ 

if  (strcmp(ent_node_ptr2->en_name,  temp_yalue) 

{ 

proc_eval_error(serror); 

in  =  TRUE; 

} 

else 

ent_node_ptrl  =  ent_node_ptrl->en_next_ent; 
ent_node_ptr2  =  ent_node_ptrl; 

} 

if  (in  ==  FALSE) 

{ 

ent_node_ptr2  =  dap  _ent_node_alloc(); 
strcpy(ent_node_ptr2->en_name,  temp_yalue); 
ent_node_ptr2->en_num_funct  =  0; 
ent_node_ptr2->en_terminal  =  FALSE; 
ent_nodejptr2->enJ|tnptr  =  NULL; 
ent_node_ptr2->en_next_ent  =  NULL; 

ent_node_ptrl  =  db_ptr->edn^ntity; 
ent  jodejptr2  =  ent_node_ptrl; 
if  (ent  node  ptr2  ==  NULL) 


db_ptr->edn_entity  =  ent^ode_ptr2; 
ent  jiode_ptr2  =  NULL; 

} 

else 

{ 

while  (ent_node_ptr2->en_next_ent  !=  NULL) 
ent_node_ptrl  =  eiit_node_ptrl->en_next_ent; 
ent_node_ptr2  =  ent  jode_ptrl; 
ent  _node_ptrl->en_next_ent  =  ent_node_ptr2; 
ent_jiode_ptr2  =  NULL; 

} 

} 

check_ids  =  FALSE; 

} 

> 

type_definition:  /*  curr^op  variables  are  set  for  subsequent  switch  statement  */ 
/*  utilization  */ 

{ 

curr_op  =  NonEnt; 

} 

enumeration_type_definition 

I 

{ 

curr_op  =  Nonrnt; 

} 

integer_type_definition 

I 

{ 

curr_op  =  NonEnt; 

} 

real_type_definition 

I 

{ 

cuiT_op  =  Derived; 

} 

derived_type_definition 


cuiT_op  =  Entity; 

} 

entity  _type_definition 

enumeration_type_definition:  LP 

/*  enumeration  dap_kms_info  structures  for  *  j 
j*  nonentity  and  function  nodes  are  initialized  */ 

{ 

checkj^ds  =  FALSE; 
switch(curr_op) 

{ 

case  NonEnt; 

kms_ptr->dki_ent  _non.enn_type  =  ’e’; 
kms_ptr->dki_ent_non.enn_range  =  FALSE; 
kms_ptr->dki_ent_non.enn_num_yalues  =  0; 
kms_ptr*>dki_ent_non.enn_constant  =  FALSE; 
break; 

case  Function: 

kms_ptr->dki_funct.fn_type  =  ’e’; 
kms_ptr->dki_^unct.fn_range  =  FALSE; 
kms_ptr->dki_funct.fn  _num_value  =  0; 
break; 

} 

} 

enumeration_literal_Jist  RP 

{ 

check_ids  =  TRUE; 

} 

enumeration_literaMist:  enumeration_literal 

/*  the  pointers  are  set  for  value  nodes  with  */ 

/•  concurrent  incrementation  of  the  number  of  */ 
j*  value  nodes  present  in  the  nonentity  and  */ 
j*  function  structures  */ 


.  •  A  ‘  A  _*-  /• 


{ 

switch(curr_op) 

{ 

case  NonEnt: 

kni8_ptr->dki_ent  jon.enn_num_yalues+  +  ; 
kms_ptr-><lki  _ent_noii.enn_value  =  entval_ptr; 
entval_ptr  =  NULL; 
break; 

case  Function; 

kms  jptr- >dki^unct.fn_num_y  aluesH-  + ; 
kms_ptr->dki_funct.fn_yalue  =  entval_ptr; 
entval_ptr  =  NULL; 
break; 

} 

} 

enumeration^iteraljlisl  COMMA  enuineration_literal 

{ 

switch(curr_op) 

{ 

case  NonEnt: 

kms_ptr-  >dki_ent_non.enn_num_v  alues+  + ; 
cntval_ptr2  =  kms_ptr->dki_ent  _non.enn_value; 
while  (entval_ptr2->ev _next_yalue  !=  NULL) 
entval_ptr2  =  entvalj)tr2->ev_next_yalue; 
entval_ptr2  =  entval_ptr; 
entval_ptr  =  NULL; 
break; 

case  Function: 

kms_ptr->dki  J|unct.fn_num_yalue+  +; 
entval_ptr2  =  km8_ptr->dki_funct.fn_yalue; 
while  (entval_ptr2->ev_next_yalue  !=  NULL) 
entval_ptr2  =  entval_ptr2->ev_next_value; 
entval_ptr2  =  entval_ptr; 
entval_ptr  =  NULL; 
break; 

} 
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} 


enuineration_literal:  n4me_id 

/*  eiit_yalue  nodes  are  allocated  and  the  ev_value  */ 
/*  pointer  is  set  the  the  appropriate  IDENTIFIER  */ 

{ 

switch(eurr_op) 

{ 

case  NonEnt: 

entval_ptr  =  dap_ent_yalue  _alloc(); 
enum_str  =  var_str  _alloc(ENlength  +  1); 
strcpy(enuni _str,  temp_yalue); 
entval_ptr->ev_yalue  =  enuin_str; 
entval_ptr->ev^ext_yalue  =  NULL; 
enum_str  =  NULL; 
break; 

case  Function: 

entva]_ptr  =  dap_ent_yalue _aJ)oc(); 
enuni_str  =  var_str  _alloc(ENlength  +  1); 
strcpy(enum_str,  teinp_yalue); 
entval_ptr->ev_value  =  enum  _str; 
entval_ptr->ev  jext_yalue  =  NULL; 
enum_str  =  NULL; 
break; 

} 

} 

I  LITERAL_CHARACTER 
{ 

switch(curr_op) 

{ 

case  NonEnt: 

entval_ptr  =  dap_ent_yalue  ^loc(); 
enuin_str  =  var_8tr _dIoc(  strlen($l)  +  1); 
strcpyfenum _8tr,  $1); 
entval_ptr->ev_ynlue  =  enuin_str; 
entval_ptr->ev_next_yalue  =  NULL; 
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enum_str  =  NULL; 
break; 

case  Function: 

entval_ptr  =  dap_ent_yalue  _alloc(); 
enuni_str  =  var_str _alloc(  strlen($l)  +  1); 
strcpy(enum_str,  $1); 
entval_ptr->ev_value  =  enuni_str; 
entval_ptr->ev  _next_yalue  =  NULL; 
enum_str  =  NULL; 
break; 


integer_type_definition: 


/*  integer  type  dap _kms_i^nfo  structures  are  set  for  */ 

/*  subsequent  insertion  into  the  schema  */ 

{ 

check_ids  =  FALSE; 
sii/itch  (cuiT_op) 

f 

\ 

CMC  NonEnt: 

kms  _ptr->dki_ent_non.enn_type  =  ’i’; 
kms_ptr->dki_ent_non.enn_range  =  TRUE; 
kms_ptr->dki_ent_non.enn_num_values  =  2; 
kms_ptr->dki_ent_non.enn_constant  =  FALSE; 
break; 

case  Derived: 

kms_ptr->dki_der_non.dnn_type  =  ’i’; 
kms_ptr->dki_der_non.dnn_range  =  TRUE; 
kms_ptr->dki_der_non.dnn_jium_yalue8  =  2; 
break; 

case  SubNon: 

km8_ptr->dki_8ub_non.8nn_type  =  ’i’; 
km8_ptr->dki  _sub_iio*;.sa«!_range  =  TRUE; 
km8_ptr->dki^ub_non.snn_num_yaIue8  =  2; 


I  i 
.v.v.v 


I  I 


CZI] 

r-'.v.  < 
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break; 


case  Function: 

kms_ptr->dki_funct.fn_type  =  ’i’; 
kins_ptr->dki_funct.fn^ange  =  TRUE; 
kms_ptr->dki_funct.fn  _num_value  =  2; 
break; 

} 

} 

integer_range 

{ 

check_ids  =  TRUE; 

} 


integer_range;  RANGE  int_range 


int  j^ange:  INTEGER  ELIPSES 

/*  The  kms_infor  value  nodes  are  allocated  and  initialized  */ 

/  •  dependent  upon  the  state  of  curr _op.  As  can  be  seen  from  * / 

/*  the  switch  rules  which  follow,  the  same  sequence  must  */ 

/•  occur  for  all  the  allowable  types.  */ 

{ 

switch  (curr_op) 

{ 

case  NonEnt: 

kms_ptr->dki_ent_non.enn_yalue  =  dap_ent_yalue_Jloc(); 
kms_ptr->dki_ent_non.enn_value->ev_yalue  =  var_str _alloc(  strlen($2)  +  1); 
strcpy(dki_ent_non.enn_yalue->ev_yalue,  $2); 
kms_ptr->dki_ent_non.enn_yalue->ev_next_yalue  =  NULL; 
kms_ptr->dki_ent  jion.enn_num_yalue8++; 
kms_ptr->dki_ent_non.enn_yalue  =  entval_ptr', 
entval_ptr  =  NULL; 
break; 

case  Derived: 

km8_ptr'>dki_der_non.dnn_value  =  dap_ent_yalue  _alloc(); 
kins_pti^>dki_derjnon.dnn_value->ev_yalue  =  var jtr _alloc(  strlen($2)  +  1); 
strcpy(dki_der _non.dnn_vnlue->ev_yalue,  32); 


kms  ptr->dki  der  jion.dnn ^’&lue->ev _next_yalue  =  NULL; 

kms  j>tr->dki_der_non.dnn_num_values+  +  ; 

kms  j>tr-'>dki_der_non.dnn_vaJue  =  entval_ptr; 

entvaJ  j>tf  =  Nl’LL; 

break; 

case  SubNon. 

kms  j)tr->dki  jub _non.snn _yalue  =  dap_ent_yalue _alloc(); 

kms_ptr->dki^ub_non.snn_yalue->ev_yalue  =  var_str _alloc(  strlen($2)  +  1) 

sircpy (dki^ubjion.snn _yalue->ev_yalue,  $2); 

kms  j)tr->dki_sub_non.snn_yalue->ev_next_yalue  =  NULL; 

kms  j)tr->dki_sub_non.snn_num_yalues++; 

kms_ptr->dki_sub  jon.snn_value  =  entval_ptr; 

entval_ptr  =  NULL; 

break; 

case  Function: 

kms_ptr->dki_funct.fn_value  =  dap _ent_yalue  _nlloc(); 
kms_ptr->dki_funct.fn_value->ev_value  =  var_8tr _alloc(  strlen($2)  1); 
strcpy(dki_funct.fn_yalue->ev_yalue,  $2); 
kms_ptr->dki_funct.fn_value->ev  j;iext_valuc  =  NULL; 
kms_ptr->dki_funct.fn_num_yalue++; 
kms_ptr->dki_funct.fn_yalue  =  entval_ptr; 
cntval_ptr  =  NULL; 
break; 

} 

} 

INTEGER 

{ 

switch  (curr_op) 

{ 

case  NonEnt: 

kms_ptr->dki_ent_iion.enn_vniue  =  dap_ent_yalue  _alloc(); 
km8_ptr->dki_ent_non.enn_yalue*>ev_ynlue  =  var _str_dloc(  strlen(Sl)  +  1); 
strcpy {dki_ent_noa.enn_y alue-  >ev_yalue,  $  1) ; 
kin8_ptr->dki_ent_non.enn_value->ev_next_yalue  =  NULL; 
km8_ptr->dki  _ent_non.enn  _num_yalues++; 
entval_ptr2  =  km8jptr->dki_ent _non.enn_yalue; 
entval_ptr2  =  entvalptr; 


entval_ptr  =  NLLL; 
break; 

case  Derived: 

kms_ptr->dki_der_non.dnn_value  =  dap_ent_yalue  _alloc(); 

kms  j>tr->dki_der_non.dnii_yalue->ev_yalue  =  var_str _alloc(  strlen($l)  1); 

strcpy (dki_der_non.dnn_vaIue- >ev_yalue,  $  1 ) ; 

kms_ptr->dki_der_non.dnn_value->ev  _next_yalue  =  NULL; 

kms_ptr->dki_der_jion.dnn_nuin_yalues+  +  ; 

entval_ptr2  =  kms_ptr->dki  _der  _non.dnn_yalue; 

eiitval_ptr2  =  entval_ptr; 

entval_ptr  =  NULL; 

break; 

case  SubNon: 

kms_ptr->dki  _subjoii.snn_va)ue  =  dap_ent_yalue  _alloc(); 

kms_ptr->dki_sub_non.dnn_yalue->ev_yalue  =  var_str _alloc(  strlen($l)  1): 

strcpy (dki_sub_non.snn_yalue->ev_value,  $1); 

kms_ptr->dki_sub  joii.snn_yalue->ev_next_value  =  NULL; 

kms_ptr->dki_jub_noii.snn_num_yaIues++; 

entval_ptr2  =  kms_ptr->dki_subjion.snn_value; 

entval_ptr2  =  entval_ptr; 

entval^ptr  =  NULL; 

break; 

case  Function: 

kins_ptr->dki_funct.fn_yalue  =  dap_ent_yalue  _aJloc(); 

kms_ptr->dki_funct.fn_yalue->ev_yalue  =  var_str _^loc(  str]en($l)  -f  1); 

strcpy (dki_funct.fn_yalue->ev_yalue,  $1); 

knis_ptr->dki^unct.fn_yalue->ev_jiext_yalue  =  NULL; 

kms_ptr->dki_funct.fn_nuni_yalue++; 

entval_ptr2  =  kin8_ptr->dki_funct.fn_yalue; 

entval_ptr2  =  entval_ptr; 

entval_ptr  =  NULL; 

break; 

} 

} 


real_ty  pe_definition : 


check_ids  =  FALSE; 
switch  (curT_op) 

{ 

case  NonEnt: 

kms_ptr->dki_ent  jon.enn_type  =  T; 
kms_ptr->dki_ent_non.enn_range  =  TRUE; 
kms_ptr->dki_ent_non.enn_nuni_values  =  2 
kinsjptr->dki_ent_non.enn_constant  =  FAL 
break; 

case  Derived: 

kms_ptr->dki_der  jon.dnn_type  =  T; 
kins_ptr->dki_der_non.dnn_range  =  TRUE; 
kms_ptr->dki_der^on.dnn_nuin_values  =  2 
break; 

case  SubNon: 

kms_ptr->dki_sub_non.snii_type  =  T; 
kms_ptr->dki_sub_non.snn_range  =  TRUE; 
kms_ptr->dki_sub_non.snn  _nuni_yaiues  =  2 
break; 

case  Function: 

kins_ptr->dki_funct.fn_type  =  T; 
kms_ptr->dki_funct.fn_range  =  TRUE; 
knis_ptr->dki_funct.fn_nuni_yalue  =  2; 
break; 

} 

} 

noat_range 

{ 

check  jds  =  TRUE; 

} 

» 

float j;ange:  RANGE  FLOAT  ELIPSES 

{ 

switch  (cuiT_op) 


case  NonEnt: 

kins_ptr->dki_ent_non.enn_yalue  =  dap_ent_yalue  _alloc{); 
kms_ptr->dki_eiit _non.enn_yalue->ev_yalue  =  var_str _^loc(  strlen($2)  +  1); 
strcpy(dki_ent _non.enn_ya]ue->ev_yalue,  $2); 
kms_ptr->dki_ent  jon.enn_ya)ue->ev  _next_yalue  =  NULL; 
kms_ptr->dki_ent  _non.enn  _nuin_yalues^  +; 
kms_ptr->dki_ent_non.enn_yalue  =  entval_ptr; 
entvaljptr  =  NULL; 
break; 

case  Derived: 

kms_ptr->dki_der_non.dnn_value  =  dap_ent_yalue  _alloc(); 
kms_ptr->dki_der_rion.dnn_vaiue->ev_yalue  =  var_str _alloc(  strlen($2)  +  1); 
strcpy(dki_der_non.dnn_value->ev_yalue,  $2); 
kms_ptr->dki_der_non.dnn_yalue->ev_next_yalue  =  NULL; 
kms_ptr->dki_der_non.dnn_num_values+-(-; 
kms_ptr->dki_der_non.dnn_yalue  =  entval_ptr; 
entval  j)tr  =  NULL; 
break; 

case  SubNon: 

kms_ptr->dki^ubjion.snn_yalue  =  dap_ent_yalue  _alloc(); 
kms_ptr->dki_sub_non.snn_yalue->ev_yalue  =  varjtr _alloc(  strlen($2)  +  1); 
strcpy(dki_sub_non.snn_yaIue->ev_yaIue,  $2); 
kms_ptr->dki_sub_non.snn_vaiue->ev_next_yalue  =  NULL; 
kms_ptr->dki_8ub_non.snn_n«m_yaIues++; 
kms_ptr->dki_8ub_non.snii_yalue  =  entval_ptr, 
entval_ptr  =  NULL; 
break; 

case  Function: 

kms_ptr->dki_funct.fn_yalue  =  dap_ent_yalue  _alloc(); 
kms_ptr->dki_funct.fn_yalue->ev_yaiue  =  var_str _alloc(  strlen($2)  +  1); 
strcpy(dki^unct.fn_yalue->ev_yaloe,  $2); 
kms_ptr->dkijunct.fn_yalue->ev_next_yalue  =  NULL; 
kins_ptr->dki_funct.fn_nuni_yalue++; 
knis_ptr->dki_funct.fn_yalue  =  entvaljptr; 
entval_ptr  =  NULL; 
break; 


FLOAT 

{ 

switch  (curr_op) 

{ 

case  NonEnt: 

kms_ptr->dki_ent  jon.enn_yalue  =  dap_ent_yalue_alloc(); 

knisj>tr->dki_ent _non.enn_ya]ue->ev_yalue  =  var _str _alloc(  strlen($l)  +  1); 

strcpy(dki_ent_non.enn_yalue->ev_yalue,  $1); 

kms_ptr->dki_ent_non.enn_value->ev_next_yalue  =  NULL; 

kms_ptr->dki_ent  _rion.enn_num_yalues++; 

entval_ptr2  =  kins_ptr->dki_ent  j;ion.enn_yalue; 

entval_ptr2  =  entval_ptr; 

entval_ptr  —  NULL; 

break; 

case  Derived; 

kms_ptr->dki_der  jion.dnn_yalue  =  dap_ent_yalue  _alloc(); 

kms_ptr->dki_der_non.dnn_yalue->ev_yalue  =  var_str __alloc(  strlen($l)  +  1); 

strcpy(dki_der_non.dnn_yalue->ev_yalue,  $1); 

kms_ptr->dki_der_non.dnn_value->ev_next_yalue  =  NULL; 

kms_ptr->dki_der  jion.dnn_num_yalues-i-+; 

entval_ptr2  =  kms_ptr->dki_der _non.dnn_yalue; 

entval_ptr2  =  entval_ptr; 

entval_ptr  =  NULL; 

break; 

case  Subnon: 

kms_ptr->dki_sub_non.snn_value  =  dr  p_ent_yalue  _alloc(); 

kms_ptr->dki_sub_non.snn_yalue->ev_yalue  =  var_str _alloc(  strlen($l)  +  l); 

strcpy(dki_sub  jon.snn_vaIue->ev_yalue,  $1); 

kms_ptr->dki_sub  _non.snn_value->ev_next_yalue  =  NULL; 

kms_ptr->dki_sub_non.snn  jium_values++; 

entvaljptr2  =  kms_ptr->dki_sub_non.snn_value; 

entval_ptr2  =  entval_ptr; 

entval_ptr  =  NULL; 

break; 

case  Function: 

kms_ptr->dki_funct.fn_yalue  =  dap_ent_yaJue  _al)oc(); 


kms_ptr->dki_funct.fn_yalue->ev^alue  =  vaj'_str _alloc(  strlen($l)  +  1); 

strcpy(dki_funct.fn_value->ev_yalue,  $1); 

kins_ptr->dki^unct.fn_value->ev_next_value  =  NULL; 

kins_ptr->dki_fmict.fn  _nuin_yalue++; 

entval_ptr2  =  kms_ptr->dki_funct.fn_yalue; 

entval_ptr2  =  entval_ptr; 

enival_ptr  =  NULL; 

break; 

} 

} 

derived_type_defintion;  NEW 

/*  the  nonentity,  subtype  nonentity,  and  derived  type  * j 
j*  nonentity  nodes  are  examined  to  find  which  con-  */ 

/*  the  current  value  of  IDENTIFIER  */ 

{ 

curr_op  =  Derived; 
check_ids  =  FALSE; 

} 

name_id 

{ 

non_ent  j>trl  =  db_ptr->edn_nonentity; 
non_ent_ptr2  =  non_ent_ptrl; 
subnon_ptrl  =  dbj)tr->edn  jonsubptr; 
subnon_ptr2  =  subnon_ptrl; 
dernon_ptrl  =  db_ptr->edn_nonderptr; 
dernon_ptr2  =  dernon_ptrl; 
ini  =  FALSE; 
in2  =  FALSE; 
in3  =  FALSE; 

while  ((non_ent_ptr2  !=  NULL)  iik.  (ini  ==  FALSE)) 

{ 

if(strcmp(non_ent_ptr2->enn_nanie,  temp_yalue)  ==  FALSE) 

{ 

ini  =  TRUE; 
strcpyjtemp,  temp_value); 


non  ent_ptrl  =  non_ent  j)trl->enn_next _node; 
non_ent_ptr2  =  non_ent  j)trl; 


while  {(subnon_ptr2  !=  NULL)  (ini  — —  FALSE)  &&  (in2 - FALSE)) 

{ 

if(strcmp(subnon_ptr2->snn _name,  tenrip_yalue)  ==  FALSE) 

{ 

in2  =  TRUE; 

strcpy (temp,  temp_yalue); 

} 


subnon_ptrl  =  subnon_ptrl->snn_next_node; 
subnon_ptr2  =  3ubnon_ptri; 


(in3  ==  FALSE)) 


while  ((dernon_ptr  !=  NULL)  &&  (ini  —  hALSE)  &&  (in2  —  FALSE) 


if(strcmp(dernon_ptr2->dnn_nanie,  temp_yalue)  ==  FALSE) 


in3  =  TRUE; 

strcpy  ( temp,  temp_yalue); 


dernon_ptrl  =  dernon_ptrl->dnn_next_node; 
dernon_ptr2  =  demon  j»trl; 


derived_range 

{ 

check_ids  =  TRUE; 

} 


.  •  .  V-  _ 


derived  ^ange:  integer_type_definition 

/  *  the  type  is  now  checked  to  see  if  in  fact  the  type  Held  */ 

/'*  in  the  kms_info  structure  actually  contains  the  value  */ 

/'*  identified  in  derived_type_definition  above  */ 

{ 

if  (ini  ==  TRUE) 

{ 

if(strcmp(kms_ptr->dki_ent_non.enn  jame,  temp)  !=  FALSE) 
proc  _e  V  al  _error  ( serror ) ; 

} 

else 

{ 

if  (in2  ==  TRUE) 

{ 

if(strcmp(kms_ptr->dki_sub_non.snn_name,  temp)  !=  FALSE) 
proc  _eval_error(serror); 

} 

else 

{ 

if  (inS  ==  TRUE) 

{ 

if(strcmp(kms_ptr->dki_der_non.dnn_name,  temp)  !=  FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

proc  _e  V  al  _error  ( serror) ; 

} 

} 

} 

} 

I  real_type_derinition 
{ 

if  (ini  ==  TRUE) 

{ 

if{strcmp(kms_ptr->dki  eat  non.enn  name,  temp)  !=  FALSE) 


proc  _e  V  al  _error  ( serror  I ; 


if  (in2  ==  TRUE) 

{ 

if(strcmp(kms_ptr->dki _sub jon.snn_name,  temp)  !=  FALSE) 
proc  _ev&l_error(serror); 

} 


If  (in3  ==  TRUE) 

{ 

if(strcmp(kms_ptr->dki_der_non.dnn _name,  temp)  !=  FALSE) 
proc  _eval_error(serror); 

} 


proc  _eval_error(serror); 


entity _type_derinition;  EMPTY 
1  ENTITY 


check_ids  =  TRUE; 

} 

entity_component_dec  laration_Iist 

{ 

check_id8  =  FALSE; 

} 

end_entity 


entity_component_declaration^ist:  entity_component_declaration 

I  entity  component  declatation  list  entity  component  declatation 


end_entity:  END 

!  END  ENTITY 

entity  _component_declat&tion: 

{ 

serror  =  5; 

} 

*************  identifierjist  COLON 

{ 

check_ids  =  FALSE; 

} 

function_type  default_yalue  SEMICOLON 

» 

function_type:  common_type 
I  FLOAT 
{ 

kjns_ptr->dki_funct,fn_type  =  T; 
km8jptr->dki_funct.fnj;ange  =  FALSE; 
kms_ptr->dki_funct.fn_total_kngth  =  FLTlength; 
knis_ptr->dki_funct.fn_num_value  =  0; 
kms_ptr->dki_funct.fn_vaiue  =  NULL; 
kms_ptr->dki^unct.fn_entptr  =  NULL; 
kms_ptr->dki_funct.fn_subptr  =  NULL; 
kms_ptr->dki_funct.fn  jonentptr  =  NULL; 
kms_ptr->dki_funct.fn_non9ubptr  =  NULL; 
kms_ptr->dki^unct.fnjionderptr  =  NULL; 
kms_ptr->dki_funct.fn_next_fntptr  =  NULL; 
kms_ptr->dki^unct.fn_entnull  =  FALSE; 
km9_ptr->dki_funct.fn_uniqu«  =  FALSE; 

} 

I  INTEGER 
{ 

kms_ptr->dki_funct.fn_type  =  ’i’; 
km9_ptr->dki_funct.fnj[ange  =  FALSE; 
km8_ptr->dki_funct.fn_total_|^ength  =  INTlength; 


kms_ptr->dki_funct.fn_num_yalue  =  0; 
kms_ptr->dki_funct.fn_y&lue  =  NULL; 
kms_ptr->dki_funct.fn_entptr  =  NULL; 
kms_ptr->dki_funct.fn_subptr  =  NULL; 
kmsjptr->dki_funct.fn_nonentptr  =  NULL; 
kms_ptr->dki_funct.fn_nonsubptr  =  NULL; 
kms_ptr->dki_funct.fn_nonderptr  =  NULL; 
kms  j)tr->dki_funct.fn  _next_fntptr  =  NULL; 
kms_ptr->dki^unct.fn_entnull  =  FALSE; 
kms_ptr->dki_funct.fn_unique  =  FALSE; 

} 

:  BOOLEAN 

{ 

kms_ptr->dki_funct.fn_type  =  ’b’; 
kins_ptr.->dki_funct.fn_range  =  FALSE; 
kms_ptr->dki_funct.fn_total_length  =  BOOLlength; 
kms_ptr->dkijrunct.fn_num_yalue  =  0; 
kins_ptr->dki^unct.fn_v’alue  =  NULL; 
kms_ptr->dki_runct.fn^ntptr  =  NULL; 
kms_ptr->dki_funct,fn_subptr  =  NULL; 
kms_ptr->dki_funct.fn_nonenlptr  =  NULL; 
kms_ptr->dki_funct.fn  _nonsubptr  =  NULL; 
kms_ptr->dki_funct.fn_nonderptr  =  NULL; 
kms_ptr->dki_funct.fn_next_fntptr  =  NULL; 
kms_ptr->dki_funct.fn_entnull  =  FALSE; 
kms_ptr->dki_funct.fn_uniqu«  =  FALSE; 

} 

I  set_type_definition 


common_type:  enumeration_type_definition 
I  integer_type_definition 
I  real_typ«_definition 
I  name_id 
{ 

non_ent_ptrl  =  db_ptr->edn_noneiitity; 
non_ent_ptr2  =  non_ent_ptrl; 
ent_ptrl  =  db_ptr->edii  _eiitity; 


ent_ptr2  =  ent_ptrl; 

gen_ptrl  =  db_ptr->edn_subptr; 

gen_ptr2  =  gen_ptrl; 

subnon_ptrl  =  db  ptr->edn  nonsubptr; 

subnonjptr2  =  subnon_ptrl; 

dernon_ptrl  =  db_ptr->edn  jionderptr; 

dernon_ptr2  =  demon  _ptrl; 

ini  =  FALSE; 

in2  =  FALSE; 

in3  =  FALSE; 

in4  =  FALSE; 

inS  =  FALSE; 

while  ((non_ent_ptr2  !=  NULL)  (ini  ==  FALSE)) 

{ 

if(strcmp(non_ent_pir2->enn_name,  temp_yalue)  ==  FALSE) 

{ 

ini  =  TRUE; 
strcpy(temp,  temp_value); 

} 

else 

{ 

non  _ent_ptrl  =  non_ent_ptrl->enn_ncxt_node; 
non  _ent_ptr2  =  non_ent_ptrl; 

} 

} 

while  ((subnon_ptr2  !=  NULL)  SiSi  (ini  ==  FALSE)  ScSc  (in2  ==  FALSE)) 

{ 

if(strcmp(subnon_ptr2->snn jname,  temp_ynluej  ==  FALSE) 

{ 

in2  =  TRUE; 
strcpy(temp,  temp_yalue); 

} 

else 

{ 

subnon_ptrl  =  subnon_ptrl->snn  jiext_node; 
subnon_ptr2  =  subnon_ptrl; 

} 


while  ((dernonjptr2  !=  NULL)  Lie  (ini  ==  FALSE)  iiL  (in2  -=  FALSE)  iik  (inS 
=  =  FALSE)) 

{ 

if(strcmp(dernon_ptr2->dnn _nanie,  teinp_yalue)  -=  FALSE) 

{ 

in3  =  TRUE; 
strcpy(temp,temp_yalue); 

} 

else 

{ 

dernonjtrl  =  dernon_ptrl->dnnjnext_node; 
dernon_ptr2  =  dernon_ptrI; 

} 

} 

while((gen_ptr2  !=  NULL)  iiti  (ini  ==  FALSE)  SiSi  (in2  ==  FALSE)  SiL  (in3  =  = 
FALSE)  kk  (in4  ==  FALSE)) 

{ 

if(strcmp(gen  j>tr2->gsn_name,  temp_yalue)  ==  FALSE) 

{ 

in4  =  TRUE; 
strcpy(temp,  temp_yalue); 

} 

else 

{ 

gen_ptrl  =  gen_ptrl->gsn  jext_genptr; 
genj)tr2  =  gen_ptrl; 

} 

} 

while((ent_ptr2  !=  NULL)  kk  (ini  ==  FALSE)  kk  (in2  ==  FALSE)  kk  (in3  == 
FALSE)  kk  (in4  ==  FALSE)  kk  (inS  ==  FALSE)) 

{ 

if(strcmp(ent_ptr2->en_nanie,  temp_yalue)  ==  FALSE) 

{ 

in5  =  TRUE; 
strcpy(temp,  temp  value); 


ent_ptrl  =  ent_ptrl->en_next_ent; 
ent_ptr2  =  ent_ptrl; 


(ini  ==  TRUE) 

func_ptrl->fn_nonentptr  =  non_ent_ptr2; 
kms_ptr->dki_funct.fn_type  =  ’v’; 


if  (in2  ==  TRUE) 

{ 

func_ptrl->fn_nonsubptr  =  subnon_ptr2; 
kms_ptr->dki_funct.fn_type  =  ’w’; 

} 


if  (in3  ==  TRUE) 

{ 

func_ptrl->fnjiond«rptr  =  dernon_ptr2; 
knis_ptr->dki_funct.fn_type  =  ’x’; 

} 


if  (in4  ==  TRUE) 

{ 

func_ptrl->fn_subptr  =  gen_ptr2; 
kin8_ptr->dki_funct.fn_typ«  =  ’y’; 

) 


if(in5  ==  TRUE) 

{ 

func_ptrl->fn_entptr  =  ent_ptr2; 
kms  ptr->dki  funct.fn  type  = 
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proc_ev  il_error(serror) ; 

} 

} 

} 

} 

} 

} 

I  string_rule 


string_rule:  STRING  LP 

{ 

kms_ptr->dki^unct.fn_type  =  ’s’; 
kms_ptr->dki_funct.fn_range  =  TRUE; 
kms_ptr->dki_funct.fn_rium_yalue  =  2; 

} 

int_range  RP 

1 

set_type_derinition:  SET  OF  commmon_type 

{  ***********  kms_ptr->dki_funct.fn_type  =  toupper(kms_ptr- 

>dki_funct.fn_type); 

} 

default_value:  empty 

I  ASSIGN  simple _con8t  SEMICOLON 

.  «***««**«*« 

> 

identifier_list;  name_id 

{ 

temp_ptr  =  kms_ptr->dki_temp_ptr; 
free_Jden  ( temp_ptr) ; 

kms_ptr->dki_temp_ptr  =  dap_ideiit_Iist  _alloc(); 
temp_ptr  —  km8_ptr->dki_temp_ptr; 
strcpy(temp_ptr->il_name,  temp_yalue); 
temp_ptr->il_next  =  NULL; 

} 

I  identifier  list  COMMA  name  id 


new_temp_ptr  =  tetnp_ptr; 
while  (new_temp_ptr->il_next  !=  NULL) 
new_temp_ptr  =  new_temp_ptr->il  jext; 
new_temp_ptr->iljext  =  dap_i^dent_Iist  ^lIoc(); 
new_temp_ptr  =  new_teinp_ptr->il_next; 
strcpy  (ne w_temp_ptr-  >il_name,  temp_y alue) ; 
new_tenip_ptr->il  _next  =  NULL; 


subtype_dec]aration;  SUBTYPE 

{ 

curr_op  =  SubTypels; 
checkjds  =  TRUE; 
serror  =  7; 

} 

name^d 

{ 

serror  =  8; 
check^ds  =  FALSE; 

} 

IS  subtype  indication  SEMICOLON 
I  SUBTYPE 
{ 

check_ids  =  FALSE; 
curr_op  =  SubTypels; 
serror  =  10; 

} 

name_id 

{ 

gen_ptrl  =  dbjptr->edn_subptr; 
gen_ptr2  =  gen_ptrl; 
ini  =  FALSE; 

while  ((gen_ptr2  !=  NULL)  SiSc  (ini  -=  FALSE)) 

{ 

if  (strcnip(gen_ptr2->gsn_name,  teinp_yalue)  ==  FALSE) 
ini  =  TRUE; 


•  '  •.•-.'-sVv'L'b Vs.' 
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gen_ptrl  =  gen_ptrl->gsn  _next_gcnptr; 
gen_ptr2  =  gen_pirl; 


if  (ini  ==  FALSE) 


proc_evs.l_error(serror) ; 


IS  namel  list 


ini  =  FALSE; 
in2  =  FALSE; 
in3  =  FALSE; 

namel  jtrl  =  kms_ptr->dki_namel_ptr; 

namel_ptr2  =  namel_ptrl; 

gen_ptrl  =  db_ptr->edn_subptr; 

gen_ptr2  =  genjtrl; 

ov€rlapsub_ptrl  =  gen_ptrl->gsn_subptr; 

overlapsub__ptr2  =  overlapsub_ptrl; 

while  (namel_pir2  !=  NULL) 

{ 

while  ((gen _ptr2  NULL)  (ini  ==  FALSE)) 

{ 

if  (strcmp(gen_ptr2->gsn_name,  namel  jptr2->il_name)  = 

{ 

ini  =  TRUE; 
in2  =  TRUE; 

if  {overlapsub_ptr2  ==  NULL) 

{ 

gen^ptrl  =  gen_ptrl->gsn_subptr; 

gen_ptr2  =  gen_ptrl; 

gen_ptr2  =  dap_overIap  _sub_node  _alloc(); 

overlap8ub_ptrl  =  genjptr2; 

overlapsub_ptr2  =  overlapsub_ptrl; 

namel_ptr2->il  _name  =  overlapsub_ptr2; 

overlapsub_ptr2->osnjiame  =  namel_ptr2->iljiame; 

overlapsub  ptr2->oen  next  name  =  NULL; 


while  (overlapsub_ptr2->oen_naine  !=  XL'LL) 
overlapsub  j)tr2  =  overlapsub_ptr2->oen_next_name; 
overlapsub_ptr2->oen_next_name  =  dap_overIap_sub_node_alloc() 
overlapsub_ptrl  =  overlapsub_ptr2->oen_next_name; 
overlapsub_ptr2  =  overlapsub_ptrl; 
namel_ptr2->il_name  =  overlapsub_ptr2; 
overlapsub_ptr2->osn_name  =  namel_ptr2->il_naine; 
ov«rlapsub_ptr2->oen_next_name  =  NULL; 

} 

} 

else 

{ 

gen_ptrl  =  gen_ptrl->gsn  _next^enptr; 
gen_ptr2  =  gen_ptrl; 

} 

} 

ent  jjtrl  =  db_ptr->edn_entity; 

ent  j)tr2  =  ent_ptrl; 

overlapent_ptrl  =  gen_ptrl->gsn_entptr, 

overlapent_ptr2  =  overlapent_ptrl; 

while  ((ent_ptr2  !=  NULL)  icSc  (in3  ==  FALSE)) 

{ 

if  (strcnip(ent_ptr2->gsn_name,  namel_ptr2->il_name)  ==  FALSE) 

{ 

in3  =  TRUE; 
in4  =  TRUE; 

if  (overlapsub_ptr2  ==  NULL) 

{ 

gen_ptrl  =  gcn_ptrl->gsn_entptr; 
gen_ptr2  =  gen_ptrl; 

gen_ptr2  =  dap_overlap_ent  jode_^loc(); 
overlapent_ptrl  =  gen_ptr2; 
overlapent_ptr2  =  overlapent_ptrl; 
nainel_ptr2->il_name  =  overlapent_ptr2; 
overlapent  ptr2->oen  name  =  namel  ptr2->il  name; 


overlapent_pir2->oen_next_name  =  NULL; 

} 

else 

{ 

while  (overlapent_ptr2->oen_name  !=  NULL) 
overlapent_ptr2  =  overlapent_ptr2->oen_next_name; 
overlapeiit_ptr2->oen_next_nanie  =  dap_overlap_ent  _node_alloc(); 
overlapent_ptrl  =  overlapent_ptr2->oen_riext_name; 
overlapent_plr2  =  overIapent_ptrl; 
namel_ptr2->il_name  =  overlapent_ptr2; 
overlapent  jptr2->oen  _name  =  namel_ptr2->il_name; 
overlapent_ptr2->oen_next_name  =  NLILL; 

} 

} 

else 

{ 

ent_ptrl  =  ent_ptrl->enjiext_ent; 
ent_pir2  =  ent 
} 


} 

if  ((in2  ==  FALSE)  kk  (in4  ==  FALSE)) 
proc  _eval  _error(serror ) ; 
else 
{ 

ini  =  FALSE; 
in2  =  FALSE; 
in3  =  FALSE; 
in4  =  FALSE; 

gen_ptrl  =  db_ptr->edn_subptr; 
gen_ptr2  =  gen_ptrl; 
naniel_ptrl  =  namel_ptrl->il  jext; 
nainel_ptr2  =  namel_ptrl; 

} 

) 

check  jds  =  TRUE; 

} 

•  entity _type_definition  SEMICOLON 
I  incomplete_subtype_declaration 
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:  4 


subtype_indication:  name_id  subtype_derinitior 
1 

subtype_definition:  RANGE  enunieration_literal  ELIPSES  enumeration_literal 
I  integer_type_derinition 
1  real_type_definition 
1  empty 
{ 

node_type  =  rind_previous(temp_vaIue,  non_ent_ptrl,  subnon_ptrl,  dernon^ptrl); 

switch  ( node  _type) 

{ 

case  NonEnt: 

subnon_ptrl  =  dap_sub_non_node  _alloc{); 
strcpy(subnon_ptrl->snn_name,  ent_non_ptrl->enn _name); 
subnon_ptrl->snnjtype  =  ent_non_ptrl->enn_type; 
subnon_ptrl->snn_totaMength  =  ent_non_ptrl->enn_lotal_lpngth; 
subnon  j)trl->snn_range  =  entjnon_ptrl->enn_range; 
subnon-ptrl->snn_num_yalues  =  ent_non_ptrl->enn_num_yalues; 
subnon_ptrl->snn_yalue  =  entjnon_ptrl->enn_yalue; 
subnon_ptrl->snn^ext_node  =  ent^on_ptrl->enn_next_node; 
subnon_ptrl  =  db_ptr->edn_nonsubptr; 
subnon_ptr2  =  subnon_ptrl; 
if  (subnon_ptr2  ==  NULL) 
db__ptr->edn  jonsubptr  =  subnon^ptrl; 
else 
{ 

while  (subnon j)tr2->snn _next ^ode  !=  NULL) 
subnon_ptr2  =  subnon_ptr2->snn  _next_node; 
subnon_ptr2->snn_next_node  =  subnon^ptrl; 

} 

subnon  jptrl  =  NULL; 
break; 

case  Derived: 

subnon_ptrl  =  dap_sub  _non_node  _alloc(); 
strcpy(subnon_ptrl->snn_nanie,  dernon_ptrl->dnn_name); 
subnon_ptrl->snn_type  =  dernon_ptrl->dnnjtype; 


»  If .'■  .  w}r];  r  m,  .n  i  buju' 


subnon_ptrl->snn_total_]ength  =  dernon_ptrl->dnn  j,otaMengih; 
subnon_ptrl->snn_range  =  dernon_ptrl->dnn_range; 
subnon-ptrl->snn_num_values  =  dernon_ptrl->dnn  j;iuin_yalues; 
subnon_ptrl->snn_value  =  dernon_ptrl->drin  j.’alue; 
subnon_ptrl->snn_next_node  =  dernon_ptrl->dnn_next_node; 
subnon_ptrl  =  db_ptr->edn_nonsubplr; 
subnon_ptr2  =  subnon_ptrl; 
if  (subnon_ptr2  ==  NULL) 
dbj)tr->edn  _nonsubptr  =  subnonjptrl; 
else 
{ 

while  (subnon_ptr2->snnj[iext_iiode  !=  NULL) 
subnon_ptr2  =  subnon_ptr2->snn_next^ode; 
subnon_ptr2->snn_next_node  =  subnon_ptrl; 

} 

subnon_ptrl  =  NULL; 
break; 

case  SubNon; 

subnon_ptrl  =  dap  _sub_non  jjode  _alloc(); 
strcpy(subnon_ptrl->8nn_naine,  subnon_ptrl->snn_name); 
subnon_ptrl->snn_type  =  subnon_ptrl->snn_type; 
subnon_ptrl->snn_totalJength  =  subnon_ptrl->snn_total_lenglh; 
subnon_ptrl->snn_range  =  subnon_ptrl->snn_range; 
subnon-ptrl->snn_num_yalues  =  subnon_ptrl->snn_nutn_yalues; 
subnon_ptrl->snn_value  =  subnon_ptrl->snn_yalue; 
3ubnon_ptrl->snn  jextjode  =  subnon_ptrl->snn_jext_node; 
subnon_ptrl  =  db_ptr->edn_nonsubptr; 
subnon_ptr2  =  subnon_ptrl; 
if  (subnon_ptr2  ==  NULL) 
db_ptr->edn_nonsubptr  =  subnon_ptrl; 
else 
{ 

while  (subnon_ptr2->snn _next _node  !=  NULL) 
subnoii_ptr2  =  subnon_ptr2->snn_next_node; 
8ubnon_ptr2->snn_next_riode  =  subnon_ptrl; 

} 

subnoii_ptrl  =  NULL; 
break; 


1S4 


type _rnark:  namel 

j  predermed_tm 

nainel_list:  namel 

{ 

temp_ptr  =  km3_ptr->dki  J^emp^ptr; 
free_ident_list.{ternp_ptr); 

kms_ptr->dki_temp  j)tr  =  dap_ident_list  _alloc(); 
temp_ptr  =  kms_ptr->dki_temp_ptr; 
strcpy  (temp_ptr->il_name,  temp_yalue); 
temp_jptr->il_next  =  NULL; 

} 

namel_list  COMMA  namel 

{ 

new_temp_ptr  =  temp_ptr; 
while  (new_temp_ptr->il _next  !=  NULL) 
new_temp_ptr  =  newr_tempjptr->il_next; 
new_temp_ptr->il_next  =  dap_ident_  Ust  _alloc(); 
new_temp_ptr  =  new_temp_ptr->il_next; 
strcpy (new_temp_ptr->il_name,  temp_yalue); 
new_temp_ptr->il_next  =  NULL; 

} 

namel:  name_id 

j  selected_component 

1 

predefined _tm:  STRING  /*  for  type  values  in  declaration  */ 
I  INTEGER 
1  BOOLEAN 
I  FLOAT 


ada_range:  simple_expression  ELIPSES  siinple_expression 


incomplete _subtype_declaration;  SUBTYPE 

{ 

check^ds  =  TRUE; 

} 

/*  entity  */ 
namejd  SEMICOLON 
{ 

in  =  FALSE; 

gen_ptrl  =  db_ptr->edn_subptr; 
while  (gen_ptrl  !=  NULL) 

{ 

if  (strcmp(gen_ptrl->gsnjiame,  temp_yalue) 

{ 

proc_eval_error(serror) ; 
in  =  TRUE; 

} 

else 

gen_ptrl  =  gen_ptrl->gsnj»extjgenptr; 
gen_ptr2  =  gen_ptrl; 

} 

if  (in  ==  FALSE) 

{ 

gen_ptr2  =  dap_gen_node  _alloc(); 
strcpy  (ge  n  jptr2-  >  gsn  _name,  temp_y  alue ) ; 
gen_ptr2->gsn_num^unct  =  0; 
gen_ptr2->gsn_terminal  =  FALSE; 
gen_ptr2->gsn_entptr  =  NULL; 
gen_ptr2->gsn_num_ent  =  NULL; 
gen_ptr2->gsn_ftnptr  =  NULL; 
gen_ptr2->gsn_subptr  =  NULL; 
gcn_ptr2->gsn  _num^ub  =  0; 
gen_ptr2-  >gsn_next_genptr; 

gen_ptrl  =  db_ptr->edn  _sabptr; 
gen_ptr2  =  gen  ptrl; 


if  (gen_ptr2  ==  NULL) 

{ 

db_ptr->edn_subptr  =  gen_ptrl; 
gen_ptr2  =  db_ptr->edn^ubptr; 
gen_ptr2  NULL; 

} 

else 

{ 

gen_ptrl  =  db_ptr->edn_9ubptr; 
gen_ptr2  =  gen_ptrl; 

while  (geii_ptr2->gsn_next_genptr  !=  NULL) 
gen_ptr2  =  gen_ptr2->gsn  _next_genptr; 
gen_ptrl->gsn_next^enptr  =  gen_ptr2; 
gen_ptr2  =  NULL; 

} 

} 

check_ids  =  FALSE; 

} 

> 

null_yalue_constraint:  WITHNULL 
I  WITHOUTNULL 


selected _component:  IDENTIFIER  DOT  IDENTIFIER 


attribute:  type_niark  HYPHEN  LP  loopjarameter  RP 

{ 

} 

j  type_mark  HYPHEN  attribute_identifier  LP  ada_express8ion  RP 


attribute_identifier:  IMAGE 
I  VAL 
I  POS 
I  VALUE 


literal:  NUMERIC_LITERAL  /*  for  user  default  type  values  in  declaration  */ 


i  LITERAL J:HARACTER 
1  CHARACTER^TRING 
1  NULL 
I  TRUE 
1  FALSE 

named _aggregate:  LP 

{ 

} 

component _Msociation^ist  RP 
;  EMPTY  j*  to  handle  case  when  no  attributes  listed  in  */ 

/*  CREATE  due  to  LR(1)  grammar  */ 

component _Msociation_list:  component _usociation 

{ 

1  component _a5sociation_|^ist  COMMA  component _usociation 

component _Msociation;  identifier_choice 

{ 

CREATE: 

} 

IMPLY  ada_expres3sion 

1 

identifier_choice:  IDENTIFIER 

{ 

} 

I  identifier_choice  IDENTIFIER 
» 

ada ^expression:  relation 
I  rel_or_list 
I  rel _xor_list 
)  rel _and_then_list 
I  rel_or_else_list 


rel  and  list:  relation  AND  relation 


rel  and  list  AND  relation 


rel_or_list:  relation  OR  relation 
1  rel  or  list  OR  relation 


rel _xor_list;  relation  XOR  relation 
j  rel_2tor_list  XOR  relation 


rel _and_then  J^ist:  relation  AND  THEN  relation 

rel  and  then  list  AND  THEN  relation 


rel_or^Ise_list;  relation  OR  ELSE  relation 

(  rel_or_else_list  OR  ELSE  relation 
;  relation;  simple  expression 


CREATE; 

(FOR  1  FOR  EACH)  k  DESTROY 
relational_operator 

CREATE: 

(FOR  1  FOR  EACH)  k  DESTROY: 
simple_expression 
I  expr_in_op  ada_range 
!  expr_in_type _mark 
)  simple_expression  test_set 
1  quantirication_clause_list  simple_expression 


siniple_expression:  term_list 

!  unary  ^operator  term_list  /*  probably  won’t  use  since  */ 


set_exp_list 


/*  involves  expressions  */ 


set_exp_list:  primary  set_operator  primary 
I  set_exp_list  set^operator  primary 


primary:  ada _name2 
I  primary2 


prim&ry2:  literal 

{ 

/*  NUMERIC_LITERAL  |  LITERAL_CHARACTER  |  CHARACTER  JTRING  |  */ 
/*  NULL  I  TRUE  |  FALSE  */ 

} 

I  set_constructor 
1  LP  ada_expression  RP 
!  indexed_coii)ponent 
> 

/*  &.C  type_conversion  is  handled  by  indexed_coinponent  */ 

indexed  ^component:  ada_name 
) 

ada_name;  ada_name2 

[  indexed_component 
1 

ada_name2:  type_rnark 

/*  ->  namell  predefined_tni(b,s,i,f)  */ 

I  function_call 
> 

terin_list:  term 

I  term_list  adding_operator  term 
1 

term:  factor_list 

1 

factor_list:  factor 

I  factor_list  multiplying_operator  factor 

J 

factor:  primary 

I  primary  EXPONENT  primary 

I 

quantirication_clause^ist:  quantirication_clause  COLON 
I  quantirication_clause_li8t 


quantirication_c]ause  COLON 

quantincatioii_clause:  FOR  quantifier  IDENTIFIER  IN  domain 

quantifier:  SOME 
i  EVERY 
I  NO 
1 

domain:  primary 

I  primary  WHERE 

1  and  ((simple_expl_list  2nd_on_simple_expl  Jist  simple_exp2_list)  j 

and  ((simple_expl  J^ist  2nd  on_simple_expl_list  simple_exp2_list) 

1 

expr_in_op:  simple_expression 
CREATE: 
in_op 

expr_jn_type^ark:  expr^n_op  type_mark 

tPit_set:  isin_operator  primary 
I  is _op  EMPTY 

1 

relational_operator:  = 


diff _op.  DIFF  I  DIFFERENCE 


inter_pp;  INTER 

I  INTERSECT 
I  INTERSECTION 

set_constructor; 

LCB 

RCB 

I  LCB  RCB  /*  empty  or  null  list  */ 

1  LCB 

I  LCB  expr^n_op  prim!iry2  WHERE  condition  RCB 

/*  because  of  primary2,  probably  not  for  CREATE  */ 

1 

function  call:  predefined  function  call 

j 

predefined_function_call;  function _name 
I  attribute 


aggregate_argument;  primary 

1  IDENTIFIER  DUPLICATES  LP  primary  RP 


function_namc:  COUNT 
I  SUM 
1  AVG 


I  MIN 
I  MAX 


»♦*•**♦****♦»*******»*****••***♦**••**♦*♦**♦***************** 
*«***«*♦«•*•*******♦•*****•♦***♦*•* ************************** 


End  of  ddl  statement 


dml^tatement:  8imple_statement 
I  compound^statement 


simple  statement:  exit_statement 


I  assignment_statement 
I  create_statement 
I  include_statement 
I  exclude^latement 
I  destroy _statement 
I  move_statenient 
I  procedure _call 

y 

exit_stateinent:  EXIT  end_exit  SEMICOLON 
1 

end _exit:  IDENTIFIER 
j  WHEN  condition 
1  IDENTIFIER  WHEN  condition 

y 

assignment_9tatement;  indexed  ^component  ASSIGN  ada_expression 

y 

create _statement;  CREATE  NEW 

check_2ds  =  FALSE; 

} 

namel_li3t 

{ 

temp^ptr  =  kms^tr->dki_temp_ptr; 
while  (temp^ptr  !=  NULL) 

{ 

ini  =  FALSE; 

ent_ptrl  =  db_ptr->edn_entity; 

while  ((ent_ptrl  !=  NULL)  (ini  ==  FALSE)) 

{ 

if  (strcinp(temp_ptr->il_naine,  ent_ptrl->en_name) 

{ 

create_liatl  =  dap_create_li8t _alloc();  must  create 
create_Ii8tl->dcIjiode_type  =  Entity; 
create^Mtl->dcI_name  =  ent_ptrl->en_name; 


create_listl->dcl^nt  j)tr  —  ent  j)trl; 
create_listl->dcl_sub  j)lr  -  NULL; 
create_listl->dcl_next  =  NLXL; 
create_list2  =  kmsjptr->dki_create.dci_create; 
if  (create_Iist2  ==  NULL) 

{ 

kms_ptr->dki_create.dci_creatc  =  create_listl; 
create_list2  =  NULL; 

} 


whi)e  (create^ist2->dcl _next  !=  NULL) 
crcate_Jist2  =  create_list2->dc}  _next; 
create_list2'>dcl  _next  =  create__listl; 
create  list2  =  NULL; 


ini  =  TRUE; 


ent_ptrl  =  ent_ptrl->en_next_ent; 


temp_ptr  =  temp_ptr->il  _next; 


temp_ptT  =  kms  _ptr->dki_teinpj>tr; 
while  (tenip_ptr  !=  NULL) 

{ 

in2  =  FALSE; 

gen_ptrl  =  dbj)tr->edn_subptr; 

while  ((gen_ptrl  !=  NULL)  kSt  {in2  ==  FALSE)) 

{ 

if  (strcmp(teinp_ptr->il_name,  gen_ptrl->g»n_naine) 

{ 

create_Iistl  =  dap_createJi8t_alloc();  must  create 
create_li8tl->dcl_node_type  =  GenSub; 
create_listl->dcl_iianie  =  gen_ptrl->gsn_iiame; 
create  li8tl->dcl_ent_ptr  =  NULL; 


create_listl->dcl_node_type  —  Entity; 
create_listl->dcl_name  =  ent  _ptr2->en_name; 
create_listl->dcl_ent_ptr  =  ent_ptr2; 
create_listl->dcl  _sub_ptr  =  NULL; 
create_list  l'>dcl_next  =  NULL; 
create_list2  =  kms_ptr->dki_create.dci_create; 
if  (create _list 2  ==  NULL) 

{ 

kms_ptr->dki_create.dci_create  =  create_listl; 
create  _list2  =  NULL; 

} 

else 

{ 

while  (create_list2->dcl_next  !=  NULL) 
create_list2  =  create_Jist2->dcl  jext; 
create  Jist2->dc] jnext  =  create_listl; 
create_list2  =  NULL; 

} 

overlapent_ptrl  =  overlapent_ptrl->oen_next_naine; 

} 

} 

if  (gcn_ptr2->gsn^ubptr  !=  NULL) 

{ 

overlapsub_ptrl  =  gsn  _subptr; 
gen_ptrl  =  overlapsub_ptrl->osn_nanie; 
while  (overlapsub_ptrl  '.=  NULL) 

{ 

create_listl  =  dap_create_list _alloc();  must  create 
create_listl->dcl  jode_type  =  GenSub; 
create_listl->dcl  jame  =  gen_ptrl->gsn_name; 
create_listl->dcl_ent_ptr  =  NULL; 
create_l^istl->dcl_sub_ptr  =  gen_ptrl; 
create_listl->dcljnext  =  NULL; 
create  Ji8t2  =  kms_ptr->dki_create.dci_create; 
if  (create_list2  ==  NULL) 

{ 

kms_ptr->dki_create.dci_create  =  create_listl; 
create_list2  =  NULL; 
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while  (create_list2->dcl jiext  !=  NULL) 
create_list2  =  create_list2->dcl_next; 
create J[ist2->dcl _next  =  create  Jistl; 
create_list2  =  NULL; 

} 

proc_create(overlapsub_ptrl->osn  _next_name); 
overlapsub_ptrl  =  overlap3ub_ptrl->osn_next  _name 
} 

} 

/*  end  recursive  procedure  */ 

} 

named _aggregate  SEMICOLON 

{ 

} 

allocator:  NEW 

namel  Jist  /*  rule  modified  to  LL(1)  from  LR(1)  */ 
named  _aggregate 

include_statement:  INCLUDE  ada  expression 
INTO  indexed_component 
SEMICOLON 

exclude_statement:  EXCLUDE  ada_expression 
FROM  indexed_component 
SEMICOLON 

> 

destroy  ^statement:  DESTROY 

ada  expression  SEMICOLON 


move^statement:  MOVE  ada_expression  move  J'rom  SEMICOLON 
I  MOVE  ada_expression  move_lo  SEMICOLON 
I  MOVE  ada_expression  move_from  move_lo  Sfi^MlCOLON 

y 

move^from;  FROM  namel_list 

I 

move_to:  INTO  namel_list 

I  INTO  namelist  named_aggregate 

procedure_caU:  procedure_name  SEMICOLON 

1  procedure  jiame  parameter_part  SEMICOLON 

} 

parameterjart:  LP  ada_expression_list  RP 

J 

procedure_name;  PRINT 
I  PRINT_LLNE 
I  CANCEL 

I  HEADER_PRINT_LINE 
I  FORMAT 
I  FORMAT_LINE 
I  HEADER  FORMAT J.INE 

i 

compound^tatement;  if_statement 
!  atomic_statement 
I  loop_statement 


if_statement;  if_part  end_if  SEMICOLON 

I  if_part  elsif_jist  end_if  SEMICOLON 
I  if _part  else _part  end_if  SEMICOLON 
1  if_part  elsif_list  else_part  end_tf  SEMICOLON 


if_part:  IF  condition  THEN  sequence_of_statements 


elsif_list;  elsif_part 

I  elsif_list  elsif_part 


elsif_part:  ELSIF  condition  THEN  sequence _of_statements 


else_part:  ELSE  sequence_of_statements 


end_tf:  END 
END  IF 

atoTnic_statement:  begin _atomic  sequence_of_stateinents 
end _atomic  SEMICOLON 

» 

begin _atomic;  ATOMIC 

I  IDENTIFIER  COLON  ATOMIC 

> 

end _aton[iic:  END 

I  END  ATOMIC 
I  END  IDENTIFIER 
I  END  ATOMIC  IDENTIFIER 


loop_statement; 

reaMoop  SEMICOLON 

1  IDENTIFIER  COLON  realjoop  IDENTIFIER  SEMICOLON 
1  IDENTIFIER  COLON  realjoop  SEMICOLON 
I  realjoop  IDENTIFIER 


realjoop:  iteration_clause  basic Joop  end Joop 


basic_loop:  seqence_of^tateinents 

i  LOOP  sequence_of_stateinents 
» 

end_loop:  END 

1  END  LOOP 

J 

.eration _clause:  iteration_body 

I  iteration _body  order_by  jclause 

iteration  _body:  for_clause  loopjparameter  IN  domain 
1 

for_clause;  FOR 

1  FOR  EACH 

loop_parameter:  IDENTIFIER 

order_by  _clause:  BY  order_component^ist 
» 

order_component_list:  order_component 

I  order_component  Jist  COMMA  order_component 

J 

order_component:  indexed_component 

I  sort_order  indexed_component 

sort_order;  ASCENDING 
1  DESCENDING 
» 

sequence_of_8tatenient9:  dml_statement 

I  sequence_of_statement9  dml_statement 


condition:  ada_expression 


generalized _expression_list:  generalized  ^expression 

I  generalized_expression_list  COMMA 
generalized_expression 


generalized_expression;  ada_expression 
I  ada_range 


ada_expression_list;  ada_expression 

:  ada _expression^ist  COMMA  ada_expression 
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